[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 <[email protected]> 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. > > [email protected] > > 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 <[email protected]> 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. > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
