Memory leak problem

Question

I have a simple program which creates a thread, and waits when this thread ends, and then the program also ends. When I compile this program with C(gcc) compiler, and check it with valgrind, no problem is occured, but when I compile it with C++(g++) compiler, and check with valgrind, it shows that my program has memory leaks. What could be the problem?

Here is my program,

#include <pthread.h>
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>


unsigned char b = 0;


void* threadfunc1( void *pVoid )
{
    while( b == 0 )
    {
    usleep(10000);
    }
    pthread_exit(0);
}



int main(void)
{

    int status;
    pthread_attr_t tattr;
    pthread_t   thread1;

    status = pthread_attr_init(&tattr);
    status = pthread_attr_setdetachstate(&tattr,PTHREAD_CREATE_JOINABLE);
    status = pthread_attr_setscope(&tattr,PTHREAD_SCOPE_SYSTEM);

    if( pthread_create( &thread1, &tattr, threadfunc1, NULL ) != 0 )
    {
        exit(1);
    }

    usleep(1000000);
    b = 1;
    pthread_join( thread1, NULL);
    usleep(2000000);

    return 0;
}

this is the result, when I compile it using g++, and check in valgrind

==7658== HEAP SUMMARY:
==7658==     in use at exit: 28 bytes in 1 blocks
==7658==   total heap usage: 2 allocs, 1 frees, 172 bytes allocated
==7658== 
==7658== 28 bytes in 1 blocks are still reachable in loss record 1 of 1
==7658==    at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==7658==    by 0x400C01E: _dl_map_object_deps (dl-deps.c:506)
==7658==    by 0x40117E0: dl_open_worker (dl-open.c:297)
==7658==    by 0x400D485: _dl_catch_error (dl-error.c:178)
==7658==    by 0x401119F: _dl_open (dl-open.c:586)
==7658==    by 0x428D0C1: do_dlopen (dl-libc.c:86)
==7658==    by 0x400D485: _dl_catch_error (dl-error.c:178)
==7658==    by 0x428D1C0: dlerror_run (dl-libc.c:47)
==7658==    by 0x428D2DA: __libc_dlopen_mode (dl-libc.c:160)
==7658==    by 0x4048876: pthread_cancel_init (unwind-forcedunwind.c:53)
==7658==    by 0x40489EC: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126)
==7658==    by 0x40464B7: __pthread_unwind (unwind.c:130)
==7658== 
==7658== LEAK SUMMARY:
==7658==    definitely lost: 0 bytes in 0 blocks
==7658==    indirectly lost: 0 bytes in 0 blocks
==7658==      possibly lost: 0 bytes in 0 blocks
==7658==    still reachable: 28 bytes in 1 blocks
==7658==         suppressed: 0 bytes in 0 blocks

So, what I'm doing wrong, is it my error or ..., why when I compile it with gcc no problems are occured and when I compile it using C++ memory leaks are present?

Writing multi-language source files is hard. Expect lots more problems. I suggest you stick to only one of C or C++. — pmg, Jun 13 '11 at 08:40
I get this program from my friend, he compile it via makefile, but I created new project in NetBeans for this program, as my default compiler is gcc, i had no problems when compile and run it, but when I compile it via makefile, I have this leaks, so it was interesting to know why? — akmal, Jun 13 '11 at 09:02

score 7 · Answer 1 · answered Jun 13 '11 at 08:23

7

As @Kiril Kirov's answer already pointed out, There are no memory leaks in your program.

But I dont see a call for:

int pthread_attr_destroy(pthread_attr_t *attr);

answered Jun 13 '11 at 08:23

Alok Save

202,538
53
430
533

About pthread_attr_destroy, it seems I deleted it when I was editing this question;). Thanks for your answer! – akmal Jun 13 '11 at 08:54
1

@akmal: That explains, why it shows no leak even if the call is missing :) – Alok Save Jun 13 '11 at 09:46

score 6 · Accepted Answer · edited May 23 '17 at 12:12

Your program don't have memory leaks, you have

==7658==    definitely lost: 0 bytes in 0 blocks
==7658==    indirectly lost: 0 bytes in 0 blocks
==7658==      possibly lost: 0 bytes in 0 blocks

"still reachable" does not mean memory leak.

There are much questions here about "still reachable" by valgrind. Some of them:

Memory leak problem

2 Answers2