fork deadlock (was: [SCM] glibc maintenance branch, t/hooks, created. glibc-2.12-869-g56798c4)

[Thomas Schwinge]

Hi!

On Fri, 11 May 2012 01:32:52 +0200, Samuel Thibault <samuel.thibault@gnu.org> 
wrote:
> Thomas Schwinge, le Thu 10 May 2012 18:09:03 +0800, a écrit :
> > Also, what about data_set_element which is only used in hurd/dtable.c for
> > _hurd_fork_locks, which is manually run through twice in
> > sysdeps/mach/hurd/fork.c, but which I can't find start and stop markers
> > being defined for?
> 
> data_set_element is something else apparently, but it seems it needs the
> same treatment indeed (I had only had a look at the hooks).
> 
> > And, might something like that in fact be responsible for the issue I had
> > already seen months ago, but have just earlier today finally posted as
> > <http://www.bddebian.com:8888/~hurd-web/open_issues/fork_deadlock/>?
> 
> Possibly.

Unfortunately that's not it: I've still been seeing that happen with the
hooks patch applied (with _hurd_fork_locks included, too) (Debian eglibc
r5251, but with the libpthread inclusion reverted for the moment).  Often
I couldn't get a single GCC build done without having it hang.  So, I
wondered why you're not seeing that on the buildds?  As I've been
compiling glibc with GCC 4.6, I reverted that to 4.4 which is the Debian
default for glibc.  And then I have been doing a lot of successful builds
without any hangs... until this morning, when I again found it hanging at
the very same place.  So it's not specifically GCC 4.6's fault either.
Someone will have to look on the critical section locking with a sharp
eye -- especially in conext with Jérémie's signalling patches, as I'm
indicating on the web page.


Grüße,
 Thomas

pgpPdi2x1TIyK.pgp
Description: PGP signature