[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ntpdate for Hurd?

On Tue, Jun 21, 2011 at 4:23 PM, Svante Signell
<svante.signell@telia.com> wrote:
> On Tue, 2011-06-21 at 15:21 +0200, Svante Signell wrote:
>> Stack corruption?? How to find out??
> I found something:
> On the box _not_ having jkoenigs patches ntpdate works fine...
> (or the problem is libc0.3: 2.13-5-> 2.13-7)

<jkoenig> gnu_srs, the hang seems to be solved by my latest libc
patches (build upcoming)
<jkoenig> what happens is that we spin on SIGALRM being intercepted by
gdb, then delivered to ntpdate after all (by default gdb does that
silently for SIGALRM),
<jkoenig> but since the signal goes through the global sigstate
pending mask, its "untracedness" is lost,
<jkoenig> ie. it' s interpreted as a signal we should stop and tell
gdb about again.
<jkoenig> the backtrace is mostly irrelevant, and the memory access
thing is only because timer_thread() is the topmost frame I guess.
<jkoenig> (the thread in question is a bare mach thread, memory is
inaccessible because we get out of the page allocated as its stack)

(see sysdeps/mach/hurd/setitimer.c)

Jérémie Koenig <jk@jk.fr.eu.org>

Reply to: