Could someone try a short program for me, please?
akuktin at gmail.com
Fri Oct 8 07:24:58 PDT 2010
>On Fri, 08 Oct 2010 13:01:11 +0200
>Simon Willcocks <simon.willcocks at t-online.de> wrote:
> I've not been keeping up with the developments on LFS for the last
> couple of years, but now I'm trying to get the latest kernel and
> glibc to run because I've run into a rather nasty problem with a
> program hanging.
> I've boiled it down to the following which generally hangs after a few
> seconds when the output is piped into "grep -n Tick" (on a dual core
> system with kernel 126.96.36.199 and glibc-2.5.1). Does anyone here have
> a more up-to-date kernel they could try it with to see if I'm barking
> up the wrong tree? When it hangs, if you debug the process it shows
> it to be stopped in a futex system call (240).
Not only does it hang when you pipe it, it also hangs on itself.
Single-core x86_64 CPU, linux-2.6.36-rc6, glibc-2.9.
#0 __lll_lock_wait_private ()
#1 0x00007f920bab449e in _L_lock_32 () from /lib/libc.so.6
#2 0x00007f920bab4365 in fwrite () from /lib/libc.so.6
#3 0x000000000040068a in ?? ()
#4 0x0000000000000001 in ?? ()
#5 0x00007fffab0f5b00 in ?? ()
#6 0x00007fffab0f5c30 in ?? ()
#7 0x0000000effffffff in ?? ()
#8 0x00007fffab0f5e98 in ?? ()
#9 0xa04beb794f4a2f82 in ?? ()
#10 0x00007fffab0f6070 in ?? ()
#11 <signal handler called>
#12 0x00007f920babc1a4 in fputc () from /lib/libc.so.6
#13 0x00000000004007ff in ?? ()
#14 0x0000000000000000 in ?? ()
__lll_lock_wait_private is implemented in Glibc and, among other
things, calls futex(2). The instruction on line 91 in lowlevellock.S is
the next after the syscall.
Given the setting, the fact that the program is multithreaded and that
both threads write to the same output stream in very short intervals,
I'd say you have a deadlock.
Changing microseconds to 1000000 (AKA, 1s) significantly increases the
time it takes for the deadlock to occur (minutes instead of seconds).
More information about the lfs-chat