From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bossom, John" To: 'reentrant' , rpj@ise.canberra.edu.au, Alastair Hume Cc: "'pthreads-win32@sources.redhat.com'" Subject: RE: Memory leak in pthread_setcanceltype()? Date: Thu, 28 Sep 2000 10:53:00 -0000 Message-id: <430F887D415DD1118C2700805F31ECF1037F1388@SOTA0005> X-SW-Source: 2000/msg00114.html I hope the following quotes help... (a bit!) >From "Programming with POSIX Threads", by David R. Butenhof, page 51: "When you no longer need a mutex that you dynamically initialized by calling pthread_mutex_init, you should destroy the mutex by calling pthread_mutex_destroy. You do not need to destroy a mutex that was statically initialized using the PTHREAD_MUTEX_INITIALIZER macro." >From "Programming with THREADS", by Steve Kleiman, Devang Shah, Bart Smaalders", page 27: "Mutexes are destroyed by calling: int pthread_mutex_destroy(pthread_mutex_t *mp); The mutex that is destroyed must have been initialized either statically or by using pthread_mutex_init()." >From "THREADS Primer, A Guide to Multithreaded Programing", by Bil Lewis and Daniel J. Berg, page 251: "... In cases where default mutex attributes are appropriate, the macro PTHREAD_MUTEX_INITIALIZER can be used to initialize mutexes that are statically allocated. The effect is equivalent to dynamic initialization by a call to pthread_mutex_init() with parameter 'attr' specified as NULL, except that no error checks are performed." (This is exactly what the man page on SOLARIS states as well) -----Original Message----- From: reentrant [ mailto:reentrant@yahoo.com ] Sent: Thursday, September 28, 2000 11:56 AM To: rpj@ise.canberra.edu.au; Alastair Hume Cc: 'pthreads-win32@sources.redhat.com' Subject: Re: Memory leak in pthread_setcanceltype()? I don't know for a fact, but I'd be leary about calling pthread_mutex_destroy() on a mutex not initialized with pthread_mutex_init() (i.e. initialied with PTHREAD_MUTEX_INITIALIZER). It feels like free()ing a pointer to a char array allocated on the stack to me. I certainly wouldn't depend on calling pthread_mutex_destroy() on a mutex not initialized via pthread_mutex_init() to be portable. >From the sound of it, to be safe I'd personally recommend avoiding the PTHREAD_MUTEX_INITIALIZER and use pthread_mutex_init() to initialize and pthread_mutex_destroy() to destroy. I've used a mutex class since 11/99 that does exactly that without any flags from purify or boundschecker (but using a 10/99 pthreads snapshot...). Dave --- Ross Johnson wrote: > Hi, > > I could be wrong since C++ is not a strongpoint for me, but your Mutex > class constructs the mutex as a PTHREAD_MUTEX_INITIALIZER but you > don't call pthread_mutex_destroy() in the destructor. The way that > pthreads-win32 implements static initialised mutexes is to calloc > the mutex struct the first time pthread_mutex_lock() is called on > that mutex. Perhaps other Pthreads implementations don't require > this but I think destroying a static mutex is legal and portable. > > Ross > > Alastair Hume wrote: > > > > Hello, > > > > I'm using Pthreads win32 (snapshot 2000-09-08) with Visual C++ (6.0) and > > Windows2000 and I am getting lots of memory leaks flagged by Purify and > > BoundsChecker. I'm using the precompiled DLL obtained from > > < ftp://sources.redhat.com/pub/pthreads-win32/dll-latest >. > > > > These leaks occur in (at least) calls to phread_mutex_lock(), > > pthread_cond_wait() and pthread_cond_timedwait() and at typically about 28 > > bytes per leak. > > > > Purify reports these memory leaks as: > > > > MLK: Memory leak of 28 bytes from 1 block allocated in > pthread_setcanceltype > > Distribution of leaked blocks > > 28 bytes from 1 block of 28 bytes (0x02105db0) > > Allocation location > > calloc [msvcrt.DLL] > > pthread_setcanceltype [pthreadVSE.dll] > > pthread_setcanceltype [pthreadVSE.dll] > > pthread_setcanceltype [pthreadVSE.dll] > > SDSUtility::Mutex::lock(void) [SDSUtility_Mutex.cpp:61] > > { > > #ifdef _MT > > > > => pthread_mutex_lock( &m_objectMutex ); > > > > #endif > > } > > and: > > > > MLK: Memory leak of 20 bytes from 1 block allocated in > pthread_setcanceltype > > Distribution of leaked blocks > > 20 bytes from 1 block of 20 bytes (0x02106200) > > Allocation location > > calloc [msvcrt.DLL] > > pthread_setcanceltype [pthreadVSE.dll] > > pthread_setcanceltype [pthreadVSE.dll] > > pthread_setcanceltype [pthreadVSE.dll] > > pthread_setcanceltype [pthreadVSE.dll] > > SDSDataStore::Query::waitForTrigger(void) > > [SDSDataStore_Query.cpp:136] > > if( !m_triggered && !m_terminated ) > > { > > => pthread_cond_wait( &m_triggered_cond, &m_mutex ); > > } > > > > BoundsChecker reports the first leak as: > > > > Bounds checker reports this as: > > > > Memory leak: 28 bytes allocated by calloc in > PTHREADVSE.DLL!00002AC1,HANDLE: > > 0x00303A10 > > PTHREADVSE.DLL!00002AC1() (unknown) (unknown) > > PTHREADVSE.DLL!00002AC1() (unknown) (unknown) > > PTHREADVSE.DLL!00002AC1() (unknown) (unknown) > > SDSUtility::Mutex::lock() > > C:\Scorpion\source\SDSUtility\SDSUtility_Mutex.cpp 61 > > > > Does anybody know if this is a known problem? Can anybody point me to > > something I could be doing wrong to cause this problem. I have tried using > > both the VSE and VCE versions. I also hacked up a simple program which > > locks and unlocks a pthread mutex and purify does not find any leaks in it > > so it is likely to be something within my more complicated program but I'm > > not sure what I can do to release memory allocated by a call to > > pthread_mutex_lock() - have I missed something? > > > > Below is my implementation of my Mutex class whose lock() methods creates > > the first leak listed above, just incase anybody can see anything obviously > > stupid in this. > > > > Any help in pointing me in the right direction would be very much > > appreciated. > > > > Thanks, > > > > Ally Hume > > Concept Systems Limited > > > > Mutex.h > > > > #include > > > > class Mutex > > { > > public: > > > > /// Constructor > > Mutex(); > > > > /// Destructor > > ~Mutex(); > > > > /** > > *** Locks the mutex. Blocks until the lock is obtained > > **/ > > void lock(); > > > > /** > > *** Unlocks the mutex > > **/ > > void unlock(); > > > > private: > > > > // Synchronization object > > > > #ifdef _MT > > > > pthread_mutex_t m_objectMutex; ///< global > > object mutex > > > > #endif > > > > }; > > > > Mutex.cpp > > > > /// Constructor > > Mutex::Mutex() > > #ifdef _MT > > : m_objectMutex( PTHREAD_MUTEX_INITIALIZER ) > > #endif > > { > > } > > > > /// Destructor > > Mutex::~Mutex() > > { > > } > > > > /** > > *** Locks the mutex. Blocks until the lock is obtained > > **/ > > void > > Mutex::lock() > > { > > #ifdef _MT > > > > pthread_mutex_lock( &m_objectMutex ); > > > > #endif > > } > > > > /** > > *** Unlocks the mutex > > **/ > > void > > Mutex::unlock() > > { > > #ifdef _MT > > > > pthread_mutex_unlock( &m_objectMutex ); > > > > #endif > > } __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/