From what I remember when playing with this stuff on g++ 2.95 the only time calling 'delete this' caused me grief was when it was called from inside a constructor, where presumably the object had not been completely constructed. These tests where only for single inheritance though.
From what you are saying though, he may be able overcome this problem by overriding Thread::close, to perform the delete this
bool m_bFakeDetach;
virtual bool isDetached()
{
if(m_bFakeDetach)
return(false);return(Thread::isDetached()); }
virtual void close()
{
m_bFakeDetach = true; //Prevent base class calling delete this
Thread::close();
delete this; //Top-level delete this
}Of course at the moment these functions are not virtual though.
David Sugar wrote:
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, although presumably it would inherit a destructor as a virtual from the underlying bases...
The Thread::close() method deletes the object through it's Thread base.
Nick Liebmann 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.
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 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 of base classes listed in the final derived class can be changed, so that TCPSession() is the first base in your derived class. In fact, I would also consider reversing the order of declaration of TCPSession in cc++/socket.h, so that public Thread appears before public TCPStream for the same reason.
I have never noticed this problem in normal (non-detached) threads, since the "delete" is always invoked against the derived class, and not a virtual base.
Rami Saarinen wrote:
Hello again,
Ia currently doing some restructuring on the program that I had probelms
with few moths ago. I just poke my editor into some very nasty stuff and
I'd like to ask if any of you have any idea why I do get a buch of Invalid
pointer error messages.
The program is heavily threaded "MessageDispatch" style of client/server
program. The proble is in the server. The server also uses xerces-c++ and
sqlite3.
I just updated common c++ form 1.0.9 to 1.3.1. None of the threads have
final() method defined and the threads are detached() and *not* started().
The invalid pointer error does not appear on 1.0.9 version.
I have been using valgrind (altought it's pthread support is incomplete)
to find another proble that will crash the program when it tries to create
XercesDOMParser. I think these problems *may* be interlinked as the crash
occurs in malloc() -> so maybe the TCPSession + other thread stuff messes
the memory so that malloc fails.
Anyway when the free(): invalid pointer 0xxxxxxxxx! appears Valgrind will
display quite many of Invalid read messages like:
==3015== Invalid read of size 4
==3015== at 0x1BD0E831: ost::Thread::close() (in
/usr/lib/libccgnu2-1.3.so.0.0.1)
==3015== by 0x1BD0FA0E:
ost::ThreadImpl::ThreadExecHandler(ost::Thread*) (in
/usr/lib/libccgnu2-1.3.so.0.0.1)
==3015== by 0x1BD0E90E: (within /usr/lib/libccgnu2-1.3.so.0.0.1)
==3015== by 0x1BCCD847: thread_wrapper (vg_libpthread.c:867)
==3015== Address 0x1BF65B98 is 240 bytes inside a block of size 416
free'd
==3015== at 0x1B90313F: operator delete(void*)
(vg_replace_malloc.c:156)
==3015== by 0x8057F87:
TCPSessionThread<AgentContainer*>::~TCPSessionThread()
(AgentContainer.cpp:125)
==3015== by 0x8057539: ost::TCPSession::final() (socket.h:1725)
==3015== by 0x1BD0E804: ost::Thread::close() (in
/usr/lib/libccgnu2-1.3.so.0.0.1)
and invalid write messages like: ==3015== Thread 4: ==3015== Invalid write of size 4 ==3015== at 0x1BD0E2EB: ost::Thread::~Thread() (in /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015== by 0x1BD0E82E: ost::Thread::close() (in /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015== by 0x1BD0FA0E: ost::ThreadImpl::ThreadExecHandler(ost::Thread*) (in /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015== by 0x1BD0E90E: (within /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015== Address 0x1BF65B34 is 140 bytes inside a block of size 416 free'd ==3015== at 0x1B90313F: operator delete(void*) (vg_replace_malloc.c:156) ==3015== by 0x8057F87: TCPSessionThread<AgentContainer*>::~TCPSessionThread() (AgentContainer.cpp:125) ==3015== by 0x8057539: ost::TCPSession::final() (socket.h:1725) ==3015== by 0x1BD0E804: ost::Thread::close() (in /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015==
But the most interesting bit is: ==3015== Thread 4: ==3015== Invalid free() / delete / delete[] ==3015== at 0x1B90313F: operator delete(void*) (vg_replace_malloc.c:156) ==3015== by 0x1BD0E320: ost::Thread::~Thread() (in /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015== by 0x1BD0E82E: ost::Thread::close() (in /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015== by 0x1BD0FA0E: ost::ThreadImpl::ThreadExecHandler(ost::Thread*) (in /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015== Address 0x1BF65B34 is 140 bytes inside a block of size 416 free'd ==3015== at 0x1B90313F: operator delete(void*) (vg_replace_malloc.c:156) ==3015== by 0x8057F87: TCPSessionThread<AgentContainer*>::~TCPSessionThread() (AgentContainer.cpp:125) ==3015== by 0x8057539: ost::TCPSession::final() (socket.h:1725) ==3015== by 0x1BD0E804: ost::Thread::close() (in /usr/lib/libccgnu2-1.3.so.0.0.1) ==3015==
I am not reserving or freeing any memory (well I do create a new srting
that will be deleted elsewhere). Any Ideas? Am I just doing All Things
Wrong? Should I consider a career change?
I'll provide any additional information you need.
Thanks again!
-- Rami Saarinen
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
_______________________________________________ Bug-commoncpp mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-commoncpp
_______________________________________________
Bug-commoncpp mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-commoncpp
_______________________________________________ Bug-commoncpp mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-commoncpp
_______________________________________________ Bug-commoncpp mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-commoncpp
