public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* RE: Memory leak in pthread_setcanceltype()?
@ 2000-09-28  9:20 Alastair Hume
  0 siblings, 0 replies; 5+ messages in thread
From: Alastair Hume @ 2000-09-28  9:20 UTC (permalink / raw)
  To: 'pthreads-win32@sources.redhat.com'

> 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.

That's what I've done now and the memory leaks have gone away.  Seems fairly
sensible to me and I'm happy with this. 

My original implementation was done after reading Butenhof's "Programming
with POSIX Threads" (Addison-Wesley) which said on page 51, "You do not need
to destroy a mutex that was statically initialized using the
PTHREAD_MUTEX_INITIALIZER macro."

Thanks to all who helped,

Ally Hume

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Memory leak in pthread_setcanceltype()?
@ 2000-09-28 10:53 Bossom, John
  0 siblings, 0 replies; 5+ messages in thread
From: Bossom, John @ 2000-09-28 10:53 UTC (permalink / raw)
  To: 'reentrant', rpj, Alastair Hume
  Cc: 'pthreads-win32@sources.redhat.com'

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 <rpj@ise.canberra.edu.au> 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 <pthread.h>
> > 
> > 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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Memory leak in pthread_setcanceltype()?
@ 2000-09-28  8:57 reentrant
  0 siblings, 0 replies; 5+ messages in thread
From: reentrant @ 2000-09-28  8:57 UTC (permalink / raw)
  To: rpj, Alastair Hume; +Cc: 'pthreads-win32@sources.redhat.com'

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 <rpj@ise.canberra.edu.au> 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 <pthread.h>
> > 
> > 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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Memory leak in pthread_setcanceltype()?
  2000-09-27  7:17 Alastair Hume
@ 2000-09-27  7:40 ` Ross Johnson
  0 siblings, 0 replies; 5+ messages in thread
From: Ross Johnson @ 2000-09-27  7:40 UTC (permalink / raw)
  To: Alastair Hume; +Cc: 'pthreads-win32@sources.redhat.com'

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 <pthread.h>
> 
> 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
> }

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Memory leak in pthread_setcanceltype()?
@ 2000-09-27  7:17 Alastair Hume
  2000-09-27  7:40 ` Ross Johnson
  0 siblings, 1 reply; 5+ messages in thread
From: Alastair Hume @ 2000-09-27  7:17 UTC (permalink / raw)
  To: 'pthreads-win32@sources.redhat.com'

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 <pthread.h>

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
}


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2000-09-28 10:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-28  9:20 Memory leak in pthread_setcanceltype()? Alastair Hume
  -- strict thread matches above, loose matches on Subject: below --
2000-09-28 10:53 Bossom, John
2000-09-28  8:57 reentrant
2000-09-27  7:17 Alastair Hume
2000-09-27  7:40 ` Ross Johnson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).