Could someone try a short program for me, please?

Aleksandar Kuktin 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 2.6.32.6 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. :)

-- 
-Aleksandar Kuktin



More information about the lfs-chat mailing list