Re: glibc 2.19 - asyn-signal safe TLS and ASan.

[Kostya Serebryany <kcc at google dot com>]

[plain text now]

Thanks again for reaching us.
The new TLS implementation *is* a problem for us as it turns out.
At least for LeakSanitizer (lsan) it will cause a false positive leak report.
Admittedly, the current lsan's implementation has an ugly hack around TLS,
which was the major reason for filing
https://sourceware.org/bugzilla/show_bug.cgi?id=16291
In short, we treat __libc_memalign called from elf/dl-tls.c in a special way
which allows us to include the dynamic TLS into the leak detector's
memory root set.
More:
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/lsan/lsan_common_linux.cc?view=diff&r1=199899&r2=199900&pathrev=199900

I suggest we continue the discussion in
https://sourceware.org/bugzilla/show_bug.cgi?id=16291
unless you prefer otherwise. Let me post more details there.

I also suspect that the new TLS implementation may cause us trouble in
MemorySanitizer,
but I haven't tried to verify that yet.


--kcc



On Tue, Jan 21, 2014 at 4:27 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> Konstantin,
>
> I've forwarded your response to libc-alpha which I assume rejected
> your multi-part plain/html email.
>
> I've also corrected the small mistake that the next release is 2.19
> not 2.20. Sorry.
>
> +address-sanitizer@googlegroups.com
>
> Hi Carlos,
>
> Thanks for the heads up!
> I don't expect any impact on ASan from this change.
> We'd still test ASan with the new glibc to make sure.
>
> --kcc
>
>
>
> On Sat, Jan 11, 2014 at 7:39 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>
>     Hello Konstantin!,
>
>     You're getting this email because you're the only ASan expert I know,
>     and I was at your talk at LFCS2013 ;-)
>
>     We have a problem and we'd like your input if you have time.
>
>     The GNU C Library version 2.20 (coming out at the end of the month)
>     plans to stop using malloc for TLS allocations. The reason for this
>     is that malloc is async-signal unsafe, and TLS accessed in signal
>     handlers may need to allocate storage at the time of access. This
>     is particularly true of signal handlers provided by dlopened shared
>     libraries. There is no way to interpose yourself here because the
>     non-malloc signal-safe allocator being used is internal to glibc.
>
>     What kind of impact do you see this having on ASan?
>
>     Do you see any way we can mitigate this impact?
>
>     Cheers,
>     Carlos.
>