[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fatal bug in class Thread, thread.cpp line~ 858
From: |
David Sugar |
Subject: |
Re: fatal bug in class Thread, thread.cpp line~ 858 |
Date: |
Sat, 20 Dec 2003 06:30:55 -0500 |
User-agent: |
KMail/1.5.3 |
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