Re: Problem in ~Thread()

[David Sugar]

In "RELEASE1", the posix version of Thread::terminate() checks to see if priv 
is NULL before it tries to do anything else, so this should be okay.  
However, the win32 version does not.  So this I see as the first problem.  In 
fact, from what I see, the win32 version never actually deletes priv or sets 
it to NULL anywhere, which is a different problem.  In "HEAD", sure enough, 
priv->_msgbuf is checked in the destructor without verifying if priv is valid 
first.  In fact, the priv->_msgbuf freeing code probably should be moved into 
terminate itself before it deletes priv (for posix).  For win32, priv 
probably should be deleted at the end of the destructor, and appropriate 
checks added to make sure a NULL priv is not being references.

On Friday 02 May 2003 07:06 am, Dimitar Dimitrov wrote:
> Hi,
>
> I think this is a bug in the Thread class and more precisely in ~Thread().
>
> The problem is that Thread::terminate() deletes and sets Thread::priv to
> NULL. If the destructor of Thread is called afterwards it tries to access
> priv->_msgbuf, whithout checking whether priv == NULL, which results in a
> segmentation fault.
>
> This is exactly what happens in SocketService destructor. It calls
> terminate ( that is Thread::terminate() ) and then ~Thread() is called.
>
> Regards,
> Dimitar
>
>
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp