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>
http://jk.fr.eu.org/
Reply to: