[ntp:questions] refclock use causes core dump of ntpd

wa6zvp wa6zvp at gmail.com
Tue Feb 20 18:55:38 UTC 2007


On Feb 20, 7:46 am, "wa6zvp" <wa6... at gmail.com> wrote:
> On Feb 19, 10:40 pm, Harlan Stenn <s... at ntp.isc.org> wrote:
>
>
>
> > Please fire up gdb again, and when it drops core type "where" to show the
> > complete stack backtrace.
>
> > It will probably take more work, but that will be a good start.
>
> > H
>
> OK, here is a start:
>
> Program received signal SIGABRT, Aborted.
> 0x282aeecb in kill () from /lib/libc.so.6
> (gdb) where
> #0  0x282aeecb in kill () from /lib/libc.so.6
> #1  0x282aee68 in raise () from /lib/libc.so.6
> #2  0x282adb78 in abort () from /lib/libc.so.6
> #3  0x0807c87f in true_doevent (peer=0x80ad2b0, event=e_Poll) at
> refclock_true.c:788
> #4  0x0807cc53 in true_receive (rbufp=0x71ff) at refclock_true.c:540
> #5  0x08053046 in ntpdmain (argc=0, argv=0xbfbfeb50) at ntpd.c:1104
> #6  0x080532ff in main (argc=1, argv=0xbfbfec7c) at ntpd.c:317
> (gdb) exit
>
> I'll be taking a look at refclock_true in the indicated area, but
> I don't pretend to be much of a programmer.:)
>
> Roger

>From the looks of it, refclock_true got into a state where it
thought that it should know what type of clock it was dealing
with, (up->type) being valid, yet it didn't.  The switch on this
variable ended up falling through to the default, which is to
abort. (crash and burn).

While I realize that this particular clock (a TT-3) isn't advertised
as being supported, I don't think the driver should get into this
state.

I don't think putting any random serial data on the input should
cause an abort.

I'll keep on trying.  Any hints on getting the driver
to log debug data, or where I should go next would be appreciated.

    Roger




More information about the questions mailing list