Help debugging
Hal Murray
hmurray at megapathdsl.net
Wed Feb 20 02:09:37 UTC 2019
I'm getting close. I'm debugging by printf. I think I just processed the
first NTS round trip. Then I get this:
19 Feb 17:58:54 ntpd[23678]: DNS: dns_take_status: rp11.example.com=>good, 0
ECR: 10, 32, 180
ECR: 13, 144, 144
ECRa: 108, 16
ECRb: 1, 108
ECR: 11, 104, 104
ECRx: 1, 8
Segmentation fault
The first question is why our trap handler isn't catching things and giving a
stack report. Note that there is now a second thread listening for TLS
initial key/cookie requests.
So I try gdb
(lots of crap snipped)
Thread 2 "ntpd" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff7839700 (LWP 24056)]
0x00007ffff7a4bf17 in accept () from /lib64/libpthread.so.0
That's the listener thread.
Here is the main thread:
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff784f740 (LWP 24041))]
#0 0x00007ffff7a41ef7 in __nptl_setxid () from /lib64/libpthread.so.0
(gdb) bt
#0 0x00007ffff7a41ef7 in __nptl_setxid () from /lib64/libpthread.so.0
#1 0x00007ffff7939f6a in setgroups () from /lib64/libc.so.6
#2 0x00007ffff7939e96 in initgroups () from /lib64/libc.so.6
#3 0x000055555556ee19 in sandbox (droproot=<optimized out>,
user=0x5555555bc260 "ntp", group=0x5555555bc280 "ntp", chrootdir=0x0,
want_dynamic_interface_tracking=<optimized out>)
at ../../ntpd/ntp_sandbox.c:175
#4 0x0000555555572c61 in ntpdmain (argc=4, argv=0x7fffffffdb98)
at ../../ntpd/ntpd.c:903
#5 0x0000555555572eb7 in main (argc=<optimized out>, argv=<optimized out>)
at ../../ntpd/ntpd.c:422
(gdb)
That doesn't make sense. It's long past the initialization stage.
Anybody familiar with debugging this sort of thing?
--
These are my opinions. I hate spam.
More information about the devel
mailing list