This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Jan 24, 2014 at 1:59 AM, Andrew Hunter <ahh@google.com> wrote:
> FYI -- you could easily do the same thing with calls to
> signal_safe_memalign from libc as a stopgap.  (Well, we'd need to
> export the symbols from libc, like I wanted to in the first place.)

Correct. If glibc lets us intercept __signal_safe_memalign&co we can
apply the same hack as we currently have.
It will not be a solution for
https://sourceware.org/bugzilla/show_bug.cgi?id=16291
but it will keep lsan and msan working with the new glibc.
How do I "export" __signal_safe_memalign? (I/d like to experiment myself)

(I've just verified that the new glibc indeed causes false positive
with MemorySanitizer,
although to be fare we have it with the old glibc too, which is another reason
why we need https://sourceware.org/bugzilla/show_bug.cgi?id=16291)

--kcc

>
> On Thu, Jan 23, 2014 at 7:35 AM, Kostya Serebryany <kcc@google.com> wrote:
>> [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.
>>>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]