Re: SMP-ix86-threads-fork: Linux 2.4.x kernel problem identified[phantom read()]

[Wolfram Gloger <wg at malloc dot de>]

> Wolfram Gloger <wg@malloc.de> writes:
> 
> > The analysis was nevertheless correct, LinuxThreads gets out of synch
> > with disastrous effects.  I was puzzled how read() could return -1,
> > however it may make sense with a __pthread_sig_cancel pending in the
> > manager thread due to a child exiting (?).  But then, why wasn't this
> > possibility discovered before?
> 
> Because we never compiled with -DDEBUG so that the ASSERT was
> triggered?

Sure, but I would have thought that this should have bitten (without
the assert) much more often.  I cannot see anything SMP-specific or
architecture-specific if the EINTR is happening.  However, I only ever
saw problems on ix86-SMP.

> There's another such place (line 135) with __libc_read in
> __pthread_manager:
> 
>   /* Synchronize debugging of the thread manager */
>   n = __libc_read(reqfd, (char *)&request, sizeof(request));
>   ASSERT(n == sizeof(request) && request.req_kind == REQ_DEBUG);
> 
> We should account for a return value of -1 here also, shouldn't we?

Yes, but that is only executed once without any threads running,
so I can't see how that 

> Is it still running? ;-)  That would be excellent!

On one machine (running 2.4.5), it eventually stopped running out of
memory for stacks, I'll investigate that more.  On my 2.4.10pre
machine at home, it ran for hours (printing out "** read err 4"
occasionally, as expected) before I turned it off to get some sleep,
and on another 2.4.0 machine, it's indeed still running without any
apparent problems.

Regards,
Wolfram.