This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 483821

Summary: memory leak in pthread_exit()
Product: [Fedora] Fedora Reporter: Vegard Nossum <vegard.nossum>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 10CC: jakub
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-03 14:20:38 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Description Flags
Reproducible test-case none

Description Vegard Nossum 2009-02-03 14:15:04 EST
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):


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== 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== 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:
Comment 1 Jakub Jelinek 2009-02-03 14:20:38 EST
Since when is reachable memory a leak?  In my book it is normal allocation.
pthread_exit (and pthread_cancel) dlopen if it hasn't been dlopened yet.
Comment 2 Vegard Nossum 2009-02-03 14:27:16 EST
(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 if it hasn't been
> dlopened yet.

Hm. The library doesn't clean up after itself. Isn't that worth fixing? :-/
Comment 3 Jakub Jelinek 2009-02-03 14:36:55 EST
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).