Re: Haunting free(): invalid pointer 0x8a11604!

[Nick Liebmann]

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 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
> > > > address@hidden
> > > > http://lists.gnu.org/mailman/listinfo/bug-commoncpp
> > >
> > >
> > >
> > > _______________________________________________
> > > Bug-commoncpp mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/bug-commoncpp
> > >  
> >
> >
> > _______________________________________________
> > Bug-commoncpp mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/bug-commoncpp