memory leak using multiple detached threads in C

Question

I am creating a server that creates a detached thread every time a client connects to the server.

    TRACE(DETAILED_TRACE,("Entered infinite loop of server.\n"));
    printf("\nThread counter = %d\n", thread_counter);
    printf("Waiting for connection...\n");

    len=sizeof(cliaddr);

    connfd=accept(sd,(struct sockaddr*)&cliaddr,&len);
    if (connfd < 0)
    {
        if (errno == EINTR)
            printf("Interrupted system call ??");
        else
            error_exit(SYSTEM_ERROR, "Connection");
    }
    if(FLAG_UNSET == server_stop_flag)
    {
        printf("Connection from %s\n",
               inet_ntop(AF_INET,&cliaddr.sin_addr,buf,sizeof(buf)));

        thread_return = pthread_create((th+thread_counter), NULL
                                       ,thread_func,(void*)&connfd);
        if(thread_return)
        {
            error_exit(SYSTEM_ERROR, "Thread Creation");
        }
        else
        {
            thread_return = pthread_detach(th[thread_counter
                                               ]);
            if(thread_return)
            {
                printf("\nError code: %d\n", thread_retu
                       rn);
                error_exit(SYSTEM_ERROR, "Detatch error"
                    );
            }
        }
        thread_counter++;
        thread_counter = thread_counter%MAX_THREADS;

while running valgrind i keep getting this:

===================================================================
16 bytes in 1 blocks are still reachable in loss record 1 of 2
   at 0x1B905301: calloc (vg_replace_malloc.c:176)
   by 0x9E7364: _dlerror_run (in /lib/libdl-2.3.4.so)
   by 0x9E6E3B: dlsym (in /lib/libdl-2.3.4.so)
   by 0x1B9106EE: open (vg_libpthread.c:2339)

LEAK SUMMARY:
   definitely lost: 0 bytes in 0 blocks.
   possibly lost:   0 bytes in 0 blocks.
   still reachable: 16 bytes in 1 blocks.
===============================================================

I keep getting the same leak summary no matter how many threads are created. since the file the leak is in is a system file and not one of my own, i have implemented something in correctly. What could it be ?

I've run the same file in valgrind on another linux server now i'm getting this:

==12599== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==12599== malloc/free: in use at exit: 136 bytes in 1 blocks.
==12599== malloc/free: 6 allocs, 5 frees, 184 bytes allocated.
==12599== For counts of detected errors, rerun with: -v
==12599== searching for pointers to 1 not-freed blocks.
==12599== checked 10,580,680 bytes.
==12599==
==12599== 136 bytes in 1 blocks are possibly lost in loss record 1 of 1
==12599==    at 0x4905D27: calloc (vg_replace_malloc.c:279)
==12599==    by 0x358500D332: _dl_allocate_tls (in /lib64/ld-2.3.4.so)
==12599==    by 0x3585F066EE: pthread_create@@GLIBC_2.2.5 (in /lib64/tls/libpthr
ead-2.3.4.so)
==12599==    by 0x401222: main (test36.c:81)
==12599==
==12599== LEAK SUMMARY:
==12599==    definitely lost: 0 bytes in 0 blocks.
==12599==      possibly lost: 136 bytes in 1 blocks.
==12599==    still reachable: 0 bytes in 0 blocks.
==12599==         suppressed: 0 bytes in 0 blocks.

Is this a problem with the server ? FYI: line no. 81 in test.c is the pthread_create call. is there something wrong with my create call ?

What version of _dlerror_run do you have? I remember it having a one off allocation bug since at least 2004. — Myforwik
Your new messages are pointing at the pthread_create() code allocating thread-local storage and not cleaning up when the thread exits. You might need to look at how your detached threads terminate, though I don't recall any special treatment being necessary. Have you ensured that all your threads have terminated before your main program exits? — Jonathan Leffler

Jonathan Leffler Jonathan Leffler · Accepted Answer · 2011-11-28T05:56:30

I don't think you have anything to worry about. The leak summary says:

LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks.
possibly lost: 0 bytes in 0 blocks.
still reachable: 16 bytes in 1 blocks.

and 'still reachable' memory has not been definitively lost, and it seems to be in system code as you identify, and it doesn't increase with number of threads, all of which adds up to "nothing to worry about" in my book.

Unless the amount of memory increases dramatically, or you can identify how it is your code that is possibly leaking memory, spend your time on other issues and not this one.

memory leak using multiple detached threads in C

3 Answers