Could someone try a short program for me, please?
akuktin at gmail.com
Fri Oct 8 08:11:46 PDT 2010
>On Fri, 8 Oct 2010 16:24:58 +0200
>Aleksandar Kuktin <akuktin at gmail.com> wrote:
> >On Fri, 08 Oct 2010 13:01:11 +0200
> >Simon Willcocks <simon.willcocks at t-online.de> wrote:
> > Hi,
> > 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 220.127.116.11 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.
> 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).
And redirecting signal handler to stderr and the main() output to
stdout eliminates the problem altogether. You can use shell to
reassemble the output, like so:
./program 2>&1 | grep -n Tick
However, in this case I seem to be missing some newlines and generally
the output is relatively malformed (but not hopelessly).
Hope I was helpful with all this. :)
More information about the lfs-chat