This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TLS redux
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Roland McGrath <roland at hack dot frob dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Mon, 27 Jan 2014 09:52:04 -0800
- Subject: Re: TLS redux
- Authentication-results: sourceware.org; auth=none
- References: <20140115022335 dot EB13174430 at topped-with-meat dot com> <Pine dot LNX dot 4 dot 64 dot 1401150520530 dot 14350 at digraph dot polyomino dot org dot uk> <CALoOobOyQxDaszErqoOkSdHsc7NestF7Pt9rS01aPzWZcnFZCQ at mail dot gmail dot com> <87r47tz5xd dot fsf at igel dot home>
On Mon, Jan 27, 2014 at 9:32 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> One example that's burned into my memory is that memory allocated by
>> ld.so's private malloc may later be free'd by public libc.so.6 free.
>
> That should not happen, and would be a major bug.
I could be mistaken, but I am 99% sure this *did* happen in glibc-2.2
- 2.5 time frame under specific (and rare) execution path with
pthread_exit from main thread or some such.
>> They are the same implementation, so no harm done, right?
>
> The ld.so malloc is a stub implementation that has nothing in common
> with libc malloc.
Currently that's the case. Was that the case in glibc-2.2?
Anyway, my point is that interposing malloc under glibc was never an
easy affair, was fraught with special cases, and Roland's claim that
we broke it by using different allocator for TLS is an
over-simplification of the reality that tools like Leak Sanitizer face
now (and will likely continue to face for a while).
--
Paul Pluzhnikov