Hi! On Fri, 11 May 2012 01:32:52 +0200, Samuel Thibault <samuel.thiba...@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
pgpJvqGccN4Mu.pgp
Description: PGP signature
