This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: tls, valgrind gdbserver and qGetTLSAddr
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 13 Aug 2014 11:55:30 -0700
- Subject: Re: tls, valgrind gdbserver and qGetTLSAddr
- Authentication-results: sourceware.org; auth=none
- References: <1407183880 dot 2180 dot 33 dot camel at soleil> <CAGQ9bdxSZU-3CrqEc9RuYGZiKNisCBv1xQnP=24iJDBEHtZKeg at mail dot gmail dot com> <1407362833 dot 2189 dot 29 dot camel at soleil>
On Wed, Aug 6, 2014 at 3:07 PM, Philippe Waroquiers
<philippe.waroquiers@skynet.be> wrote:
> On Wed, 2014-08-06 at 17:17 +0400, Konstantin Serebryany wrote:
>> This question rings the bell...
>> https://sourceware.org/ml/libc-alpha/2014-04/msg00313.html
>> https://sourceware.org/glibc/wiki/ThreadPropertiesAPI
>
> Yes, there are similarities in some of the needs.
> There are also some differences, e.g. Valgrind observes
> most of what happens by intercepting or wrapping syscalls
> or glibc calls (eg pthread creation or dead) and
> Valgrind (at least currently) is also not supposed to call any
> library to do its work (this is why valgrind cannot use
> libthread_db).
>
> On the tls and lsan false positive leak:
> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/lsan/lit_tests/TestCases/use_tls_dynamic.cc?view=markup&pathrev=200748
> I tested this with valgrind.
> The block of size 1337 is found reachable,
> as the tls block is itself found reachable via a 4K block
> mmap-ed by:
> Thread 1: status = VgTs_Runnable
> ==3515== at 0x209283: mmap (mmap.S:65)
> ==3515== by 0x207CE8: __libc_memalign (dl-minimal.c:79)
> ==3515== by 0x203661: _dl_allocate_tls_storage (dl-tls.c:345)
> ==3515== by 0x1F450C: init_tls (rtld.c:767)
> ==3515== by 0x1F66AE: dl_main (rtld.c:1855)
> ==3515== by 0x207616: _dl_sysdep_start (dl-sysdep.c:243)
> ==3515== by 0x1F3272: _dl_start (rtld.c:333)
> ==3515== by 0x1F2856: ??? (in /lib/ld-2.11.2.so)
>
> Isn't lsan observing the mmap-ed blocks ?
lsan can not observe mmap syscalls (or any other syscalls).
It can only observe libc function calls done via PLT
Currently, lsan does not have a false positive here because it
intercepts __libc_memalign.
At some point before glibc 2.19 release glibc trunk used another
allocator which lsan was not able to intercept and we had a false
positive.
> That should be sufficient to avoid the false positive leak ?
>
> Philippe
>
>