At Wed, 4 May 2005 14:11:38 +0200, Miquel van Smoorenburg wrote: > Christian Hammers wrote: > > For what it's worth, I also tried Miguel's ctime-hang.c on both a Sarge i386 > > and a Sid amd64 machine with 2.6 kernels and can reproduce the hang in > > 10 of 10 attempts. > > I also re-ran the ctime-hang.c test program on i386 uniprocessor > and SMP, and amd64 SMP (all up-to-date sarge and 2.6 kernel) and > ctime-hang.c locked every time right away.
I confirm that Miquel's ctime-hang.c stops its execution on 2.6 kernel + the latest glibc. Recent glibc switches to use NPTL instead of LinuxThreads when 2.6 kernel is used. If you set environment variable LD_ASSUME_KERNEL=2.4.1 and rerun his programs on 2.6 kernel, the problem is just disappeared (because LinuxThreads is used). Note that NPTL uses futex for mutex protection, instead LinuxThreads uses signal. SUSv3, aka POSIX, defines the signal handler safe functions as follows: http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04 Unfortunatelly, ctime() is not defined on this list. So, glibc does not guarantee the sane behavior when one uses ctime() in signal handler. BTW, I'm surprised that sysklogd calls some functions in signal handler. I have not reappeared sysklogd breakage yet, but IMHO this problem is potentially existed - I agreed Miquel's proposal. Miquel, did you confirm this problem using sysklogd? If this patch fixes this bug, I think we should do NMU for sarge. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
