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