This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TLS redux
- From: Rich Felker <dalias at aerifal dot cx>
- To: Jason Evans <jasone at canonware dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Andreas Schwab <schwab at linux-m68k dot org>, "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: Tue, 28 Jan 2014 20:23:16 -0500
- 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> <CALoOobNZVFQ7z0uOgp6zAKMk7fmx03ua6S5E24UNgtVM3o=etQ at mail dot gmail dot com> <61CF7641-148C-4D7B-BE80-A1E3CC0AA498 at canonware dot com>
On Mon, Jan 27, 2014 at 11:25:27AM -0800, Jason Evans wrote:
> On Jan 27, 2014, at 9:52 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> > 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).
>
> Here's a slight variation on how the non-hermetic ld.so design can
> bite:
>
> http://www.canonware.com/pipermail/jemalloc-discuss/2013-November/000663.html
>
> In short, ld.so doesn't save/restore floating point state when
> calling into malloc, which can corrupt application state as a side
> effect of lazy symbol loading.
Yet another reason that failing to save/restore the FULL register set
on lazy symbol resolution is a bug that should be fixed on all archs,
rather than being swept under the rug with excuses.
Rich