Attempt to free unallocated or already freed object inside fork() in a multithreaded program

[blackwater]

> Do you have a way to duplicate the problem without using librtc by monitoring the values sent to free in your test case?

Dennis, I can reproduce this problem when I use libtcmalloc.so with a program. TCMalloc is a third party library and it checks a pointer that was given to free(). However since TCMalloc is a third party library HP does not accept this way of demonstrating a problem. By the way my program is actually used with TCMalloc.

So, libRTC is the only way to demonstrae a problem.

[Dennis Handly · Accepted solution]

>librtc is the only way to demonstrate a problem.

You could also demonstrate it by setting a breakpoint at malloc return and free entry and record the values and see if they

match.  (But that's easier if there are fewer calls.  :-)

Or in this case, make sure that the free value is less than the current break value.  Since this is a mmap return, this would be way bigger.

>sometimes I've got no reports about invalid calls to free(), sometimes I've up to five or six reports

Of course this is the scary thing, it may be timing related.

I did figure out why librtc is getting a signal 11.  It checks if larger than the heap base and keeps incrementing.  As soon as it crosses the page boundary, it dies.

And the mmap regions are above the heap!

So this indicates there is a bug in librtc.  And at least that should be filed.

(This is in your message 6.)

I'm still able to duplicate this with "check_leaks=off" and all calls to pthread_setspecific, pthread_key_create and pthread_key_delete removed.

Note to get valid corefiles you need something like: coreadm -p "core.%p"