desertcoder - Re: stl / pthreads leak, patch (original) (raw)

This is the mail archive of the libstdc++@gcc.gnu.orgmailing list for the libstdc++ project.

• From:
• To: libstdc++ at gcc dot gnu dot org
• Date: Mon, 12 Aug 2002 16:20:10 -0400
• Subject: Re: stl / pthreads leak, patch

Sorry. My last post did not completely display the memory leak problem. Here is a better example:

//////////////////////////////////////////////////////////////////// // BEGIN: stl_leaker.cpp // //////////////////////////////////////////////////////////////////// #define _GNU_SOURCE #define _REENTRANT #define _THREAD_SAFE #include <pthread.h> #include #include #include <unistd.h> using namespace std;

void *processClient(void *clientArgs); pthread_attr_t attrDetached; pthread_attr_t attrJoinable;

int strMultiplier = 10;

int main(int argc, char **argv) { int numThreads = 40; pthread_attr_init(&attrDetached);

pthread_attr_setdetachstate(&attrDetached, PTHREAD_CREATE_DETACHED);
pthread_attr_setdetachstate(&attrJoinable, PTHREAD_CREATE_JOINABLE);

pthread_t clientThread;	//Threads are detached, don't care about handle			
for ( int threadCount = 0; threadCount <= numThreads; threadCount++ ) {
            
    if ( (pthread_create(&clientThread, &attrDetached, processClient, (void *)NULL)) != 0 ) {
        cout << endl << "ERROR: Could not create client thread.";					
        break; 
    }							
}
sleep(10); //Make sure all detached threads have a chance to return	
pthread_attr_destroy(&attrDetached);
cout << endl << "DONE !" << endl;		
return 0;

}

void *processClient(void *clientArgs) { string s1, s2, s3, s4, s5, s6; s1.assign("blah123"); s2.assign("blah123blah123"); s3.assign("blah123blah123blah123"); s4.assign("blah123blah123blah123blah123");

int r = 5  * strMultiplier;
for ( int i = 0; i <= r; i++  ) {
    s5.assign(s1 + s2);
    s1.assign(s5);
}		
s6.assign(s3 + s2 + s1);
    
return NULL; 

}

//////////////////////////////////////////////////////////////////// // END: stl_leaker.cpp // ////////////////////////////////////////////////////////////////////

When strMultiplier = 10, Valgrind reports:

==11851== LEAK SUMMARY: ==11851== definitely lost: 0 bytes in 0 blocks. ==11851== possibly lost: 0 bytes in 0 blocks. ==11851== still reachable: 9528 bytes in 4 blocks.

When strMultiplier = 100, Valgrind reports:

==18111== LEAK SUMMARY: ==18111== definitely lost: 3544 bytes in 2 blocks. ==18111== possibly lost: 125904 bytes in 37 blocks. ==18111== still reachable: 45704 bytes in 14 blocks.

Can anyone make sense of this?

Ken