main thread's pthread destructors don't run before leak checker, when in gdb

[GoogleCodeExporter]

What steps will reproduce the problem?

todd@todd-ThinkPad-T540p:/tmp$ cat test.cc
#include <pthread.h>

void Cleanup(void* t) {
  delete (int*)t;
}

int main(int argc, char** argv)
{
    pthread_key_t key;
    pthread_key_create(&key, &Cleanup);
    pthread_setspecific(key, new int(12345));

    return 0;
}
todd@todd-ThinkPad-T540p:/tmp$ clang++ -fsanitize=address -pthread  -o test 
test.cc
todd@todd-ThinkPad-T540p:/tmp$ ./test
todd@todd-ThinkPad-T540p:/tmp$ gdb --batch -ex 'run' ./test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

=================================================================
==32689==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x434b3b (/tmp/test+0x434b3b)
    #1 0x4b9e39 (/tmp/test+0x4b9e39)
    #2 0x7ffff6becde4 (/lib/x86_64-linux-gnu/libc.so.6+0x21de4)

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
[Inferior 1 (process 32689) exited with code 027]

What is the expected output? What do you see instead?

I expect the pthread TSD destructors to run before LSAN checks for leaks. It 
seems to work this way outside of gdb, but when running in gdb, it detects a 
leak.

What version of the product are you using? On what operating system?

clang version 3.6.0 (trunk 223108)
GNU gdb (GDB) 7.9

Original issue reported on code.google.com by t...@cloudera.com on 19 Mar 2015 at 11:35

[GoogleCodeExporter]

Even slightly simpler, to get rid of c++ism:

#include <pthread.h>
#include <stdlib.h>
int main(int argc, char** argv)
{
    pthread_key_t key;
    pthread_key_create(&key, &free);;
    pthread_setspecific(key, malloc(1));
    return 0;
}

Original comment by t...@cloudera.com on 19 Mar 2015 at 11:38

[GoogleCodeExporter]

Fun. When both lsan and gdb play dirty tricks with TSD, gdb wins. :) 
I don't think we will treat this as high priority, but thanks for the report 
anyway.

Original comment by konstant...@gmail.com on 19 Mar 2015 at 11:45

[GoogleCodeExporter]

Running LSan under GDB is not supported. This report happens because LSan fails 
to attach to the main thread (as GDB is already attached to it) and 
subsequently ignores any thread-local data coming from that thread.

I wonder if we should just crash whenever there's at least one thread we can't 
attach to.

Original comment by earth...@chromium.org on 23 Mar 2015 at 1:25

[GoogleCodeExporter]

In preference to crashing, I'd rather just having a report at program 
termination that says "Leak detection skipped: unable to attach to thread <X> 
(perhaps running under GDB?)" or something like that. Or, still report the 
leaks, and note that there may be false positives due to failure to attach to 
some thread(s)? I regularly run ASAN builds in gdb, and it would be annoying to 
have to always remember to set ASAN_OPTIONS=detect_leaks=0 before doing so.

Original comment by t...@cloudera.com on 23 Mar 2015 at 5:27