Actually the problem was also present with older versions. Not 1.0.9
thought, but if I recall right the invalid pointer started to appear in
1.1.0 or something like that. That's one of the reasons why I did not
update earlier.
Furthermore doing the solution 2 does get rid of the invalid pointer
e
I think you are absolutely correct that the key should be cleared if
th->isDetach() is true before calling th->close() and letting it fall
through the rest of the code. The threadKey for "self" is also used so
that arbitrary code can determine and manipulate the actual Thread
"object" that is
Well the destructor in the derived class is empty.
Really the problem is ThreadImpl::ThreadDestructor checks th->priv, from
an object 'th' which has already been deleted, in the case of a detached
thread.
Im not really sure of the reasons for the ThreadKey class, but reading
the pthread document
Ah, I think I might see...both the exit handling for close is called, as
is the destructor, which includes terminate() that does some other
stuff? What does the destructor in your derived object look like?
Nick Liebmann wrote:
As a penance for trying to sort out this problem with an old version
HmmI think for now it should be conditional, at least until we can
look at a detailed analysis of any misbehaving non-detached thread. In
the case of non-detached threads, after the thread is cancelled and
joined, there is still some interactions happening in the destructor as
terminate()
As a penance for trying to sort out this problem with an old version of
the library, I have taken a look with the latest version.
Here are my discoveries:
As previously stated 'delete this' is called from Thread::close(), and
there seems to be no reason to assume anything is wrong with this call
--- Nick Liebmann <[EMAIL PROTECTED]> wrote:
>
> Ok, your problem is that the TCPSession::final calls delete this when
> the thread ends.
>
> Your choices are
>
> 1) Dont call tcp->detach(), call start()... the thread will be deleted
> automaticall by TCPSession::final
> 2) override virtual
Apologies, I am using an older version of common c++
David Sugar wrote:
In older versions of the library you would use "delete this" for
detached threads. In the current (1.3) releases, you should NEVER do
this. That final() was appearently leftover from before detach
behavior was changed. In
In older versions of the library you would use "delete this" for
detached threads. In the current (1.3) releases, you should NEVER do
this. That final() was appearently leftover from before detach behavior
was changed. In 1.?2? and definately 1.3, detach deletes the the thread
the object for
Ok, your problem is that the TCPSession::final calls delete this when
the thread ends.
Your choices are
1) Dont call tcp->detach(), call start()... the thread will be deleted
automaticall by TCPSession::final
2) override virtual void final() in TCPSessionThread, to do nothing.
For the library, TCPS
--- Nick Liebmann <[EMAIL PROTECTED]> wrote:
> I would also suggest declaring empty virtual destructors for any
> inherited classes for which you have no specific
> need for a destructor. I dont really know why this should be necessary,
> but for some reason (at least in the past)
> I have found
I would also suggest declaring empty virtual destructors for any
inherited classes for which you have no specific
need for a destructor. I dont really know why this should be necessary,
but for some reason (at least in the past)
I have found this necessary, and now do it as a habit.
An isolated
--- Nick Liebmann <[EMAIL PROTECTED]> wrote:
>
> Following on from this, I'd be inclined to check that all of your
> destructors are declared as virtual, and you are not deleting objects
> multiple times.
>
>
At first I want to thank you all for the replies.
To give a high level rundown o
I am not sure the virtuality of a destructor is inherited but definitly
with the gnu compiler I have had issues where not declaring a virtual
destructor causes a whole host of problems.
From what I remember when playing with this stuff on g++ 2.95 the only
time calling 'delete this' caused me g
Thread definately is declared with a virtual destructor, and so is
Socket. TCPStream, inherited from Socket, also redeclares a virtual
destructor, and TCPSession has no declared destructor at all, although
it inherits both TCPStream and Thread. I am not sure what his
"TCPSessionThread" has, a
Following on from this, I'd be inclined to check that all of your
destructors are declared as virtual, and you are not deleting objects
multiple times.
Nick
David Sugar wrote:
Hmm...perhaps it is a dynamic casting issue. The thread close method
itself is only really aware of a "Thread" object
In fact, I will go a step further...Thread() is built with a virtual
destructor...it appears to me that virtual destructors are not working
correcting on your compiler. This would explain the memory offset of
the delete free() operation in Thread::close, which I am guessing is
likely the offse
Hmm...perhaps it is a dynamic casting issue. The thread close method
itself is only really aware of a "Thread" object as the base class
itself, at that point in time. If it is unable to handle the delete of
the derived virtual object by recasting the pointer references, then
perhaps the order
18 matches
Mail list logo
