This is the mail archive of the libc-help@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] |
hi, The attached testcase leaks 400000 bytes: [mathieu@mathieu-laptop test]$ valgrind --leak-check=full --show-reachable=yes ./test10 ==3381== Memcheck, a memory error detector. ==3381== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==3381== Using LibVEX rev 1884, a library for dynamic binary translation. ==3381== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==3381== Using valgrind-3.4.1, a dynamic binary instrumentation framework. ==3381== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==3381== For more details, rerun with: -v ==3381== libtest10 constructor enter main main i=1 th i=1 th i=2 main i=1 th i=1 th i=2 main i=1 main i=1 th i=1 th i=2 main i=1 th i=1 th i=2 main i=1 leave main libtest10 destructor ==3381== ==3381== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 2) ==3381== malloc/free: in use at exit: 800,032 bytes in 3 blocks. ==3381== malloc/free: 30 allocs, 27 frees, 3,206,192 bytes allocated. ==3381== For counts of detected errors, rerun with: -v ==3381== searching for pointers to 3 not-freed blocks. ==3381== checked 494,024 bytes. ==3381== ==3381== 32 bytes in 1 blocks are still reachable in loss record 1 of 3 ==3381== at 0x4A05414: calloc (vg_replace_malloc.c:397) ==3381== by 0x339E80130F: _dlerror_run (in /lib64/libdl-2.10.2.so) ==3381== by 0x339E800EE0: dlopen@@GLIBC_2.2.5 (in /lib64/libdl-2.10.2.so) ==3381== by 0x400A3B: test_one (test10.c:31) ==3381== by 0x400BA3: main (test10.c:65) ==3381== ==3381== ==3381== 400,000 bytes in 1 blocks are still reachable in loss record 2 of 3 ==3381== at 0x4A05260: memalign (vg_replace_malloc.c:460) ==3381== by 0x339DC1123F: tls_get_addr_tail (in /lib64/ld-2.10.2.so) ==3381== by 0x339DC1175F: __tls_get_addr (in /lib64/ld-2.10.2.so) ==3381== by 0x502E66F: ??? ==3381== by 0x400B1F: test_one (test10.c:49) ==3381== by 0x400BA8: main (test10.c:66) ==3381== ==3381== ==3381== 400,000 bytes in 1 blocks are definitely lost in loss record 3 of 3 ==3381== at 0x4A05260: memalign (vg_replace_malloc.c:460) ==3381== by 0x339DC1123F: tls_get_addr_tail (in /lib64/ld-2.10.2.so) ==3381== by 0x339DC1175F: __tls_get_addr (in /lib64/ld-2.10.2.so) ==3381== by 0x502E66F: ??? ==3381== by 0x4009DA: thread (test10.c:21) ==3381== by 0x339EC06859: start_thread (in /lib64/libpthread-2.10.2.so) ==3381== by 0x339E0DE22C: clone (in /lib64/libc-2.10.2.so) ==3381== ==3381== LEAK SUMMARY: ==3381== definitely lost: 400,000 bytes in 1 blocks. ==3381== possibly lost: 0 bytes in 0 blocks. ==3381== still reachable: 400,032 bytes in 2 blocks. ==3381== suppressed: 0 bytes in 0 blocks. [mathieu@mathieu-laptop test]$ I looked a bit in this: it looks like there is a missing call to _dl_deallocate_tls which makes the dynamic loader leak the memory pointed to by one of the dtv[i] entries. When my thread terminates, queue_stack is called by __deallocate_stack by __free_tcb by start_thread. queue_stack adds the thread data structure in the free list of stacks and it is then unqueued from this list upon the next call to pthread_create by get_cached_stack. What appears to go really wrong here is that get_cached_stack uses memset to clear the content of the reused dtv and then _dl_allocate_tls_init to re-initialize it. It looks like the memset should be replaced by something like _dl_deallocate_tls to give the dynamic loader a chance to free the entries dtvi points to. Mathieu -- Mathieu Lacage <mathieu.lacage@gmail.com>
Attachment:
libi.c
Description: Text document
Attachment:
test10.c
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |