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:
0x22daff10-0x22daff1f
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:
0x22db0500
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]
