Bug 303691 - pthread create/join may be leaking memory according to valgrind
pthread create/join may be leaking memory according to valgrind
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: glibc (Show other bugs)
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2007-09-24 13:34 EDT by Kim van der Riet
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-25 09:59:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Kim van der Riet 2007-09-24 13:34:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20070718 Fedora/ Firefox/

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:

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

void* do_it(void*) {

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:
==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== 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:
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 13:41:45 EDT
Created attachment 204341 [details]
Full text of valgrind output from this reproducer
Comment 2 Jakub Jelinek 2007-09-25 09:59:58 EDT
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.