TLS redux

[Paul Pluzhnikov]

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