Bug 483821 - memory leak in pthread_exit()
memory leak in pthread_exit()
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
10
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-03 14:15 EST by Vegard Nossum
Modified: 2009-02-03 14:36 EST (History)
1 user (show)

See Also:
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:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproducible test-case (222 bytes, text/plain)
2009-02-03 14:15 EST, Vegard Nossum
no flags Details

  None (edit)
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):

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:
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 libgcc_s.so.1 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 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? :-/
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).

Note You need to log in before you can comment on or make changes to this bug.