win32 thread class bug

[Ralph Dellamorte]

I see that this problem has been previously discussed as shown below. I am 
using the latest version commoncpp2-1.1.1 on a windows machine am am having 
this problem. Any help would be appreciated :)

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:34:57 -0500
User-agent:  KMail/1.5.3

--------------------------------------------------------------------------------

Actually thats not correct either, since _self is part of the current "Thread"
object.  What would be better, as a temporary solution, is to change "final"
so that it can return a bool, and have it return true when final has deleted
the current object...that way any further processing could be bypassed if
final is true.  Let me think more on this....

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