Package: glibc Severity: grave Tags: sarge On Fri, 2005-01-28 at 09:48 -0800, David Mosberger wrote: > Hi Dann, > > I don't seem to be getting much traction in getting the NPTL ld.so bug > resolved. I posted a glibc bug-report: > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=685
<Including report inline here> Several of us noticed that evolution on Debian/unstable sometimes crashes early during program startup. It turns out that the crash is due to memory corruption. In one particular case, the memory that got corrupted was in the address range: 0x2000000002daff10-0x2000000002daff1f which happened to hold the function descriptors for shared library linkage stubs ("jump slots"). Of relevance was that the thread-pointer (r13) had the value: 0x2000000002db0500 The corruption was caused by any NPTL routine trying to access the thread-descriptor, since NPTL uses a "struct pthread" of size 1680 bytes (0x690). I believe the problem is due to the fact that /lib/ld-linux-ia64.so.2 was built for Linux Threads, which uses a thread descriptor size of 0x500. Note that sysdeps/generic/dl-tls.c has several references to TLS_PRE_TCB_SIZE for the case where TLS_DTV_AT_TP is defined. In other words, ld.so ends up having a dependency on the size of the thread-descriptor. Sure enough, if I invoke evolution like this: /lib/tls/ld-linux-ia64.so.2 evolution it works just fine. My understanding is that /lib/ld-linux-ia64.so.2 should work for both NPTL and LinuxThreads libraries and the dependency on the size of the thread-descriptor is accidental. I believe this same bug may affect Alpha, PowerPC, and SH. For Alpha, I found this bug report, which sounds potentially related: http://sources.redhat.com/bugzilla/show_bug.cgi?id=299 > > and sent a mail to libc-hacker: > > http://sources.redhat.com/ml/libc-hacker/2005-01/msg00071.html > > and there has been no response whatsoever so far. I'm not sure what > the original authors had in mind here, so I'm not sure what the proper > way is to fix this problem. > > A stop-gap solution might be to just do: > > # mv /lib/tls/ld-2.3.2.so /lib/ > > I did this on my Debian/unstable system and it seems to work just > fine. I did verify beforehand that the two versions of ld-2.3.2 do > export the exact same set of symbols, so this ought to be fairly safe. > It works around the bug since the NPTL value of TLS_PRE_TCB_SIZE is > bigger than that for LinuxThreads. > > Perhaps this should be the recommended workaround for Debian for the > time being? I'm CC'ing Al Stone - maybe he has a suggestion with how to interact w/ glibc upstream, or what the proper fix may be. I'm filing this bug as release critical, given it causes memory corruption on potentially 4 architectures. If the glibc maintainers disagree, I'm sure they'll downgrade. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]