Bug 303691 - pthread create/join may be leaking memory according to valgrind
Summary: pthread create/join may be leaking memory according to valgrind
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: glibc
Version: 5.0
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-24 17:34 UTC by Kim van der Riet
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-09-25 13:59:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Full text of valgrind output from this reproducer (5.37 KB, text/plain)
2007-09-24 17:41 UTC, Kim van der Riet
no flags Details

Description Kim van der Riet 2007-09-24 17:34:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070718 Fedora/1.5.0.12-4.fc6 Firefox/1.5.0.12

Description of problem:
Valgrind reports "still reachable" record for pthread_create() and pthread_join() pair. Trivial reproducer included below.

Occurs on both 32 and 64-bit RHEL 5, but not on Fedora Core 5 (I have not tested later Fedora releases).

Version-Release number of selected component (if applicable):
glibc-2.5-12, kernel-2.6.18-8.1.10.el5

How reproducible:
Always


Steps to Reproduce:
1.Trivial reproducer phtread.cpp:
#include <stdio.h>
#include <pthread.h>

void* do_it(void*) {
    printf("Hello!\n");
}

int main(int argc, char** argv) {
    pthread_t t;
    pthread_create(&t, NULL, do_it, NULL);
    pthread_join(t, NULL);
}

2.g++ -g -lpthread pthread.cpp -o pthread
3. valgrind -v --track-fds=yes --leak-check=full --leak-resolution=high --show-reachable=yes ./pthread

Actual Results:
<snip>
==9446== 2,048 bytes in 1 blocks are still reachable in loss record 1 of 1
==9446==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==9446==    by 0x4A05883: realloc (vg_replace_malloc.c:306)
==9446==    by 0x36E1E06D19: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.5.so)
==9446==    by 0x40064E: main (pthread.cpp:10)
==9446== 
==9446== LEAK SUMMARY:
==9446==    definitely lost: 0 bytes in 0 blocks.
==9446==      possibly lost: 0 bytes in 0 blocks.
==9446==    still reachable: 2,048 bytes in 1 blocks.
==9446==         suppressed: 0 bytes in 0 blocks.


Expected Results:
<snip>
All heap blocks were freed -- no leaks are possible.

Additional info:
I am uncertain of the true significance of this; I raise this in case it may be important. Valgrind docs suggest that this kind of error is the result of "sloppy programming", but may be common and may not be considered serious.

This problem has cropped up in a relatively recent update to RHEL5 (I am unable to say exactly when, however) as system tests which run valgrind for a component I am working on and which uses pthreads passed in the past, but now fails with this error.

Comment 1 Kim van der Riet 2007-09-24 17:41:45 UTC
Created attachment 204341 [details]
Full text of valgrind output from this reproducer

Comment 2 Jakub Jelinek 2007-09-25 13:59:58 UTC
That's not a leak, just glibc-rh210748-workaround.patch allocating a chunk
of memory on first pthread_create.  It is not freed in __libc_freeres, because
it might still be used at that point.
Anyway, RHEL5.1 glibc has backported real fix instead of this workaround.


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