4

I'm using pthreads and according to valgrind I am leaking memory, like in valgrind memory leak errors when using pthread_create

The top answer says that if you pthread_join all the threads this memory will be reclaimed, but it isn't for me.

pthread_t threads[NUM_THREADS];
...
for (i = 0; i < NUM_THREADS; i++) {
    pthread_create(&threads[i], &attr, Worker, NULL);
}
...
for (i = 0; i < NUM_THREADS; i++) {
    pthread_join(threads[i], NULL);
}

valgrind output

==2707== HEAP SUMMARY:
==2707==     in use at exit: 954 bytes in 4 blocks
==2707==   total heap usage: 7,717 allocs, 7,713 frees, 79,563 bytes allocated
==2707== 
==2707== 34 bytes in 1 blocks are still reachable in loss record 1 of 4
==2707==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2707==    by 0x400541E: local_strdup (dl-load.c:162)
==2707==    by 0x40085D3: _dl_map_object (dl-load.c:2473)
==2707==    by 0x4012D5C: dl_open_worker (dl-open.c:225)
==2707==    by 0x400ECBE: _dl_catch_error (dl-error.c:178)
==2707==    by 0x4184D40: do_dlopen (dl-libc.c:89)
==2707==    by 0x404CD4B: start_thread (pthread_create.c:308)
==2707==    by 0x414BACD: clone (clone.S:130)
==2707== 
==2707== 34 bytes in 1 blocks are still reachable in loss record 2 of 4
==2707==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2707==    by 0x400B05A: _dl_new_object (dl-object.c:161)
==2707==    by 0x4006437: _dl_map_object_from_fd (dl-load.c:1051)
==2707==    by 0x400839F: _dl_map_object (dl-load.c:2568)
==2707==    by 0x4012D5C: dl_open_worker (dl-open.c:225)
==2707==    by 0x400ECBE: _dl_catch_error (dl-error.c:178)
==2707==    by 0x4184D40: do_dlopen (dl-libc.c:89)
==2707==    by 0x404CD4B: start_thread (pthread_create.c:308)
==2707==    by 0x414BACD: clone (clone.S:130)
==2707== 
==2707== 256 bytes in 1 blocks are still reachable in loss record 3 of 4
==2707==    at 0x402A5E6: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2707==    by 0x401045C: _dl_check_map_versions (dl-version.c:300)
==2707==    by 0x401336A: dl_open_worker (dl-open.c:268)
==2707==    by 0x400ECBE: _dl_catch_error (dl-error.c:178)
==2707==    by 0x4184D40: do_dlopen (dl-libc.c:89)
==2707==    by 0x404CD4B: start_thread (pthread_create.c:308)
==2707==    by 0x414BACD: clone (clone.S:130)
==2707== 
==2707== 630 bytes in 1 blocks are still reachable in loss record 4 of 4
==2707==    at 0x402A5E6: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2707==    by 0x400AE0F: _dl_new_object (dl-object.c:77)
==2707==    by 0x4006437: _dl_map_object_from_fd (dl-load.c:1051)
==2707==    by 0x400839F: _dl_map_object (dl-load.c:2568)
==2707==    by 0x4012D5C: dl_open_worker (dl-open.c:225)
==2707==    by 0x400ECBE: _dl_catch_error (dl-error.c:178)
==2707==    by 0x4184D40: do_dlopen (dl-libc.c:89)
==2707==    by 0x404CD4B: start_thread (pthread_create.c:308)
==2707==    by 0x414BACD: clone (clone.S:130)
==2707== 
==2707== LEAK SUMMARY:
==2707==    definitely lost: 0 bytes in 0 blocks
==2707==    indirectly lost: 0 bytes in 0 blocks
==2707==      possibly lost: 0 bytes in 0 blocks
==2707==    still reachable: 954 bytes in 4 blocks
==2707==         suppressed: 0 bytes in 0 blocks
==2707== 
==2707== For counts of detected and suppressed errors, rerun with: -v
==2707== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Am I doing something wrong or is the top answer incorrect?

Community
  • 1
  • 1
Tim
  • 11,710
  • 4
  • 42
  • 43

2 Answers2

4

This is not an actual leak and you can safely ignore it. The memory block pthread_create allocates is used for extending the thread stack and it is not freed. The library may use the same memory region for possible future calls to pthread_create.

perreal
  • 94,503
  • 21
  • 155
  • 181
  • In a previous project I used pthreads and did not have this issue, but in this project I am. Why would it be happening this time? I start and stop the threads in the exact same way. – Tim Oct 30 '12 at 05:12
  • It might be because of the library version. Look into to the code of the allocate_stack function if you like: http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=nptl/allocatestack.c;hb=HEAD – perreal Oct 30 '12 at 05:14
  • 2
    That's the confusing part, I pthread_join each thread and there is still a leak. – Tim Oct 30 '12 at 05:18
0

I am probably late to the show. As pointed out, it must not have any memory leak - I checked what you have done it is standard way of creating (create internal memory for thread) and joining a thread (auto reclaims this memory).

However, you have not shown the initialization of attr.

You may try doing: 

pthread_create(&threads[i], NULL, Worker, NULL);

I have placed NULL here, instead of any value for attr. The pthread initialization is tightly coupled to attribute (unless it is provided as NULL).

Sammy
  • 257
  • 2
  • 8