Created attachment 330768 [details] Reproducible test-case Description of problem: Valgrind reports a (reachable) memory leak when pthread_exit() is called. Version-Release number of selected component (if applicable): glibc-2.9-3.x86_64 How reproducible: Every time Steps to Reproduce: 1. g++ -Wall pthread_exit.c -lpthread (see attachment) 2. valgrind --leak-check=full --show-reachable=yes ./a.out Actual results: ==5763== malloc/free: in use at exit: 56 bytes in 1 blocks. ==5763== malloc/free: 2 allocs, 1 frees, 344 bytes allocated. ==5763== For counts of detected errors, rerun with: -v ==5763== searching for pointers to 1 not-freed blocks. ==5763== checked 184,264 bytes. ==5763== ==5763== 56 bytes in 1 blocks are still reachable in loss record 1 of 1 ==5763== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==5763== by 0x36CCA0CF78: _dl_map_object_deps (dl-deps.c:507) ==5763== by 0x36CCA133B4: dl_open_worker (dl-open.c:330) ==5763== by 0x36CCA0E745: _dl_catch_error (dl-error.c:178) ==5763== by 0x36CCA12C3A: _dl_open (dl-open.c:596) ==5763== by 0x36CDF21A6F: do_dlopen (dl-libc.c:86) ==5763== by 0x36CCA0E745: _dl_catch_error (dl-error.c:178) ==5763== by 0x36CDF21BD6: __libc_dlopen_mode (dl-libc.c:47) ==5763== by 0x36CEA0F82B: pthread_cancel_init (unwind-forcedunwind.c:47) ==5763== by 0x36CEA0F93F: _Unwind_ForcedUnwind (unwind-forcedunwind.c:98) ==5763== by 0x36CEA0D78F: __pthread_unwind (unwind.c:130) ==5763== by 0x36CEA07B24: pthread_exit (pthreadP.h:264) ==5763== ==5763== LEAK SUMMARY: ==5763== definitely lost: 0 bytes in 0 blocks. ==5763== possibly lost: 0 bytes in 0 blocks. ==5763== still reachable: 56 bytes in 1 blocks. ==5763== suppressed: 0 bytes in 0 blocks. Expected results: (no reachable memory on exit) Additional info:
Since when is reachable memory a leak? In my book it is normal allocation. pthread_exit (and pthread_cancel) dlopen libgcc_s.so.1 if it hasn't been dlopened yet.
(In reply to comment #1) > Since when is reachable memory a leak? In my book it is normal allocation. > pthread_exit (and pthread_cancel) dlopen libgcc_s.so.1 if it hasn't been > dlopened yet. Hm. The library doesn't clean up after itself. Isn't that worth fixing? :-/
The library doesn't dlopen libgcc_s every time such function is called, that would be a performance nightmare. So it remains dlopened for all following pthread_cancel/pthread_exit calls. The reason why it isn't dlclosed during __libc_freeres (which is run just by valgrind and other memory allocation checkers, normally there is no point in freeing memory upon exit) is that the risks (some other thread could be calling pthread_cancel/pthread_exit concurrently) far overweight the possible gains (valgrind/mtrace being quiet).