[ Please CC replies to me, thanks ] Thanks for writing to the list. People need to be able to find these kinds of problems with google, so they know what the situation is and what their options are.
> The core issue as I remember it was that the NPTL in 2.3.2 libc6 was > borken version 0.70. We had to switch distributions that had 2.3.4 or > 2.3.5 libc6 instead of 2.3.2. For me, it's not a problem running with the LD_ flag to tell the system to not use NPTL. I'm curious why that isn't the default though, if the problem is indeed in libc6. To me, this looks ever more likely, as more people try and hammer on the Tcl bug and can't reproduce it on other systems: http://sourceforge.net/tracker/index.php?func=detail&aid=1220692&group_id=12997&atid=112997 > From the old bugs about it there were patches, and I'm guessing it's > possible upgrade just the underlying nptl code of libc. > > It's this bug, but there may be others. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108631 Yes, I found that as well, and it seemed very likely. If one reads my messages to the Tcl bug report, in one of them I traced the cond_wait's and broadcasts, and it really looks as if one of the wait's isn't returning, despite having been woken up. That doesn't seem like it could be Tcl's fault.... > Perhaps once a 2.3.5 libc6 moves into unstable Debian can be used again. I'm ok with the export LD_ASSUME_KERNEL=2.4.1 workaround myself, but I'm left scratching my head some by the whole mess. Thankyou, -- David N. Welton - http://www.dedasys.com/davidw/ Apache, Linux, Tcl Consulting - http://www.dedasys.com/
