Re: win32 thread class bug

[David Sugar]

The solution we use in 1.1.1 to this problem is very simple.  You NEVER use 
"delete this" in final().  Rather if the thread is a "detached" thread (a 
concept that exists in posix, in w32 there originally was no distinction) the 
thread will now automatically delete itself as it actually is terminated.  So 
just use detach() rather than start(), and do NOT use "delete this"...

On Thursday 25 March 2004 11:31 am, Ralph Dellamorte wrote:
> 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
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp