Segmentation fault running ntpd
David Wolfskill
david at catwhisker.org
Fri Jul 24 13:03:20 UTC 2015
On Sun, Jul 19, 2015 at 11:36:00AM -0700, David Wolfskill wrote:
> On Sun, Jul 19, 2015 at 10:24:11AM -0600, Ian Lepore wrote:
> > ...
> > Was there anything (at all) in /var/log/messages about ntpd? Even the
> > routine messages (such as what interfaces it binds to) might give a bit
> > of a clue about how far it got in its init before it died.
> > ....
>
> Sorry; there might have been something yesterday...
> If I do get another recurrence, I'll try to gather a bit more
> information.
> ....
OK; got another one.
This time, I have the complete /var/log/messages for a verbose boot,
from that boot to just a bit after the ntpd crash; it's in
<http://www.catwhisker.org/~david/FreeBSD/head>; as of the moment, that
contains:
[PARENTDIR] Parent Directory -
[ ] CANARY 2015-03-22 10:03 15K
[ ] CANARY.gz 2015-03-22 10:03 6.3K
[ ] ntpd.core 2015-07-24 05:31 13M
[ ] ntpd.core.gz 2015-07-24 05:31 124K
[TXT] ntpd_crash_msgs.txt 2015-07-24 05:40 138K
[ ] ntpd_crash_msgs.txt.gz 2015-07-24 05:40 19K
This was running:
FreeBSD g1-245.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #133 r285836M/285836:1100077: Fri Jul 24 05:24:41 PDT 2015 root at g1-245.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64
Trying "gdb /usr/obj/usr/src/usr.sbin/ntp/ntpd/ntpd ntpd.core" still
doesn't help much:
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `ntpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
...
Loaded symbols for /libexec/ld-elf.so.1
#0 0x00000008011cd6a0 in sbrk () from /lib/libc.so.7
[New Thread 801c07400 (LWP 100133/<unknown>)]
[New Thread 801c06400 (LWP 100132/<unknown>)]
(gdb) bt
#0 0x00000008011cd6a0 in sbrk () from /lib/libc.so.7
#1 0x00000008ccbd4f34 in ?? ()
#2 0x0000000000000005 in ?? ()
#3 0x0000000801800448 in ?? ()
#4 0x00000008011ca888 in sbrk () from /lib/libc.so.7
#5 0x00000008018000c8 in ?? ()
#6 0x00000008018000c0 in ?? ()
#7 0x0000000000000208 in ?? ()
#8 0x0000000801c32fb0 in ?? ()
#9 0x0000000000000001 in ?? ()
#10 0x0000000801cc20c8 in ?? ()
#11 0x0000000000000030 in ?? ()
#12 0x0000000801cc20c8 in ?? ()
#13 0x00007fffffffe480 in ?? ()
#14 0x00000008011cd240 in sbrk () from /lib/libc.so.7
#15 0x0000000000000280 in ?? ()
#16 0x00000008014bbc70 in malloc_message () from /lib/libc.so.7
#17 0x00000008018000c0 in ?? ()
#18 0x0000000801800448 in ?? ()
#19 0x0000000000000032 in ?? ()
#20 0x0000000801800458 in ?? ()
#21 0x00000008014bbc68 in malloc_message () from /lib/libc.so.7
#22 0x0000000801cc2000 in ?? ()
#23 0x00000008014bba60 in malloc_message () from /lib/libc.so.7
#24 0x0000000801cc20d8 in ?? ()
#25 0x00000000000000a0 in ?? ()
#26 0x0000000000000208 in ?? ()
#27 0x00007fffffffe4d0 in ?? ()
#28 0x00000008011bdd7a in _malloc_thread_cleanup () from /lib/libc.so.7
Previous frame inner to this frame (corrupt stack?)
(gdb)
I am presently suspecting that it's a bit dependent on ... well, "timing".
I have my ~/.xsession set up so that once I've entered the passphrase(s)
for my SSH private key(s), scripts start running to establish
connections to other machines -- e.g., open an xterm locally, ssh
over to my mailhub and (re-)establish a tmux session on that machine
where I run mutt to read & write email (such as this message).
While that almost always Just Works in stable/10, it's rather ...
spottier ... in head -- I'd say it's about a 50% probability that it will
work, vs. the ssh connection attempt hanging, and eventually timing out.
But if I've waited (say) 30 seconds or so, I can establish such a
connection easily.
Granted, I am using wireless (802.11), but I get a sense that "things"
are claimed to be "ready to go" a bit prematurely -- at least sometimes.
Peace,
david
--
David H. Wolfskill david at catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20150724/c6430955/attachment.bin>
More information about the freebsd-current
mailing list