bug-commoncpp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread: memory leak when using not detached thread?


From: David Sugar
Subject: Re: Thread: memory leak when using not detached thread?
Date: Tue, 10 Dec 2002 09:53:13 -0500 (EST)

First, you should not detach in the destructor unless it is in it's own
context.  If anything, perhaps detach() vs terminate() should be called
depending on the circumstances, on whether it is being deleted by self or
by another thread, which, I think would be valid, otherwise, if another
thread calls detelete xxx, it will suddenly detach itself :).  Also, as
noted earlier, some glibc releases definately had a bug where a detached
thread that terminates never released resources, which is why I tended to
avoid them.

On Tue, 10 Dec 2002, Vass Andras wrote:

> Thread are created joinable by default - at least in commoncpp2-1.0.7.
> >From the libc info pages:
> "When a joinable thread terminates, its memory resources (thread
>      descriptor and stack) are not deallocated until another thread
>      performs `pthread_join' on it. Therefore, `pthread_join' must be
>      called once for each joinable thread created to avoid memory leaks."
> The problem can be solved if you detach the thread in the Thread::~Thread
> destructor,
> right before calling terminate (See below)
> 
> ps: has anynone taken a look at the bug report on savannah.gnu.org?
> 
> Thread::~Thread()
> {
> #ifdef WIN32
>   terminate();
> 
>   if (isThread())
>   {
>     priv->_tid = 0;
>     _self.setKey(DUMMY_INVALID_THREAD);
>   }
>   if (priv->_hThread) CloseHandle(priv->_hThread);
>   if (priv->_cancellation) CloseHandle(priv->_cancellation);
> 
> #else
>   detach();
>   if(this != &_mainthread){
>     terminate();
>   }
> #endif // WIN32
> }
> 
> ----- Original Message -----
> From: "David Sugar" <address@hidden>
> To: "Gernot Hillier" <address@hidden>
> Cc: <address@hidden>
> Sent: Tuesday, December 10, 2002 3:19 PM
> Subject: Re: Thread: memory leak when using not detached thread?
> 
> 
> >
> > A thread cannot delete it's own context or join itself.  To make a thread
> > that is a self running object that self-deletes, one has to detach the
> > thread.  However, there is very definately a known bug in at least some
> > glibc releases that when a detached thread exits, it will not clean up
> > it's stack frame allocations because that code only existed in the
> > pthread_join implimentation, and, of course, one cannot self join...
> >
> > On Mon, 9 Dec 2002, Gernot Hillier wrote:
> >
> > > --[PinePGP]--------------------------------------------------[begin]--
> > > Hi!
> > >
> > > I'm no pthread guru, so perhaps I've misunderstood something. Please
> excuse
> > > this ;-)
> > >
> > > I narrowed my problem down to a very small test application. See
> attached
> > > test.cpp file.
> > >
> > > This program produces a memory leak - i.e. a finishing thread doesn't
> free its
> > > resources.
> > >
> > > I had a small look on the sources and the problem seems to be in
> > > Thread::terminate():
> > >
> > >         if(pthread_self() != priv->_tid)
> > >         {
> > >                 printf("grbml\n");
> > >                 // in suspend thread cannot be cancelled or signaled
> > >                 // ??? rigth
> > >                 // ccxx_resume(priv->_tid);
> > >
> > >                 // assure thread has ran before we try to cancel...
> > >                 if(_start)
> > >                         _start->post();
> > >
> > >                 pthread_cancel(priv->_tid);
> > >                 pthread_join(priv->_tid,NULL);
> > >         }
> > >
> > > This doesn't get called as pthread_self() seems to be the same thread
> which
> > > deletes this. So pthread_join isn't called and the resources aren't
> freed.
> > >
> > > Now I thought Thread::final() won't run in the same thread context as my
> new
> > > thread? So why doesn't this work?
> > >
> > > Do I have to use Thread::detach() instead of Thread::start() when I want
> to
> > > "delete this"?
> > >
> > > Could you elaborate on the cited glibc bug mentioned in the
> Thread::detach()
> > > docu? I asked a glibc developer and he told me that it's my fault if I
> don't
> > > run pthread_join - no glibc bug.
> > >
> > > I've seeked the archives a  little bit but found no mail responding my
> > > question. Sorry if this is a FAQ.
> > >
> > > --
> > > Ciao,
> > >
> > > Gernot
> > > "Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das
> nennen
> > > sie ihren Standpunkt." (A. Einstein)
> > > --[PinePGP]-----------------------------------------------------------
> > > gpg: Warning: using insecure memory!
> > > gpg: Signature made Mon 09 Dec 2002 05:12:42 AM EST using DSA key ID
> 619E49E2
> > > gpg: Can't check signature: public key not found
> > > PinePGP: Encryption backend encountered error.
> > > --[PinePGP]----------------------------------------------------[end]--
> > >
> >
> >
> >
> > _______________________________________________
> > Bug-commoncpp mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> >
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]