Re: [Fwd: Re: Haunting free(): invalid pointer 0x8a11604!]

[David Sugar]

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 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. 
> All destructors are called appropriately.
>
> The problem valgrind reports is that an access is being made to an 
> already deleted chunk of memory, and it seems to be correct...
>
> After the 'delete this' pthread_exit(NULL) is called, which causes a 
> call to ccxx_thread_destructor, which itself calls 
> ThreadImpl::ThreadDestructor.
>
> ThreadImpl::ThreadDestructor checks th->priv which is illegal, because 
> th (the thread) has been deleted.
>
> This is where my knowledge of pthreads becomes flaky, but I reckon this 
> is being called due to the ThreadKey object still having a reference to 
> the thread
>
> Inserting the line:
> ThreadImpl::_self.setKey(NULL);
> before the call to th->close() in 
> ThreadImpl::ThreadExecHandler(Thread*th) sorts out the problem, however 
> I am not actually sure of  the side effects of this call. Maybe is 
> should be conditional, depending on the detached state of the thread.
>
> David... its over to you
>
> Nick
>
>
>
> 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 1.?2? and definately 1.3, detach deletes the 
> > the thread the object for you after you exit() the thread, and does it 
> > through the virtual destructors via the Thread base class.
> >
> > Nick 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 void final() in TCPSessionThread, to do nothing.
> > >
> > > For the library, TCPSession::final should say if(!isDetached()) 
> > > delete this;
> > >
> > > Rami Saarinen wrote:
> > >
> > > > --- Nick Liebmann <address@hidden> 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 this necessary, and now do it as a habit.
> > > > >
> > > > > An isolated test-case is definitly the way to go!
> > > > >   
> > > >
> > > >
> > > >
> > > >
> > > > Well I just can't get it any simpler than this. Invalid pointer is 
> > > > still
> > > > present exactly like before. Am I missing something? Brains?
> > > >
> > > > I am using cc++ 1.3.1, gcc 3.3.3 20040412, Fedora Core 2 (Linux). 
> > > > cc++ was
> > > > compiled on this machine. testlistener is the test program.
> > > >
> > > > TCPListener is the one that will create TCPSessionThread per connection
> > > > when there are connections pending.
> > > > TCPSessionThread does nothing at all (and the invalid pointer error
> > > > appears in destructor).
> > > >
> > > > I linked it with -lccgnu2 -ldl  (used also -lpthread, but it is not 
> > > > needed
> > > > really).
> > > >
> > > > Valgrind gives this when connecting the test program and sending 
> > > > some text
> > > > to it: 
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Bug-commoncpp mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/bug-commoncpp

dyfet.vcf
Description: Vcard