Bug#292673: NPTL vs. LinuxThread sizeof(struct pthread) conflict causes memory corruption
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.
Reply to: