Re: fatal bug in class Thread, thread.cpp line~ 858

[David Sugar]

In theory, when the thread is deleted, the key values held for the thread by 
getKey() should also be cleared.  In practice, I gather this does not happen 
in w32 targets.  Hmm, perhaps the thread delete needs to explicitly reset 
_self.getKey() to NULL for w32.

On Friday 19 December 2003 08:54 am, Tobias Erbsland wrote:
> Hello
>
> The Thread class has a fatal bug:
>
> ==== thread.cpp ==== Line 848 ====
>       // final can call destructor (that call Terminate)
>       final();
>
>       // test if this class have been deleted
> #ifdef WIN32
>       if (_self.getKey() == this)
> #else
>       if (ThreadImpl::_self.getKey() == this)
> #endif
>       {
>               if(priv)
>                       priv->_tid = 0;
>               joinSem.post();
>       }
> ====================================
>
> The API documentation suggest to place a "delete this" in the final()
> method to delete the thread on exit. This implementation is found for
> example in the TCPSession class.
>
> After the final() method, the object could be deleted, so each access to
> a member of the object is invalid.
>
> The C++ compiler from the new .NET edition of the MS Visual Studio
> (Version 7.0) fills each deleted memory segment with the "word" 0xfeee
> in debug mode (i don't know why, but that's the fact).
>
> The line "if(priv)" is true in this case, and the assignment "priv->_tid
> = 0" results in an access violation (unix: core dump).
>
> IMHO, instead this strange test, there should be a hook in the virtual
> destructor of the Thread class.
>
> regards
> Tobias