Bug 483821 - memory leak in pthread_exit()
Summary: memory leak in pthread_exit()
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 10
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-03 19:15 UTC by Vegard Nossum
Modified: 2009-02-03 19:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-03 19:20:38 UTC
Type: ---
Embargoed:


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

Description Vegard Nossum 2009-02-03 19:15:04 UTC
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 19:20:38 UTC
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 19:27:16 UTC
(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 19:36:55 UTC
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.