Core dump (heap corruption)

[prabhakarbhatt]

I am getting following dump trace. Pls can some help what would be causing the heap corruption.

Program terminated with signal 11, Segmentation fault.
SEGV_ACCERR - Invalid Permissions for object
#0  0xc0000000003ad110:1 in tree_delete+0xd1 () from /usr/lib/hpux64/libc.so.1
(gdb) #0  0xc0000000003ad110:1 in tree_delete+0xd1 () from /usr/lib/hpux64/libc.so.1
#1  0xc0000000003a84c0:0 in real_free+0x600 () from /usr/lib/hpux64/libc.so.1
#2  0xc0000000003b3210:0 in free+0x170 () from /usr/lib/hpux64/libc.so.1
#3  0x4000000000ff0e70:0 in operator delete[] ()
   

[Dennis Handly]

You should be using gdb's heap checking to see where you are corrupting the heap:

set heap-check on

[prabhakarbhatt]

Dennis,

Thanks for your quick reply.

I will try to get this done as we need to repro this.

Need one help from you :

I feel  0x4000000000ff0e70:0 in operator delete[] ()
    at build/OCSCframeworks/code/MemoryHandler/MemHandler.C:538 is causing the process to dump. Pls can you confirm is my understanding correct.

[Dennis Handly]

>I feel operator delete[] is causing the process to dump.

Not likely, unless it is passing a non-heap address to free.

Most likely the heap has been corrupted before and operator delete[] is just the victim.

[prabhakarbhatt]

Thanks dennis.

Agreed for your comment, Will check that. Just thinking double delete or free may also cause such issues? Pls could you comment on this.

[Dennis Handly]

>Just thinking double delete or free may also cause such issues?

Yes, those too.

[prabhakarbhatt]

Hi Danny,

I think is it hard to put gdb on that pltfrorm as it is production. And we dont know the exact scenario to repro.

Only option left is to debug the core file. Pls can you suggest some pointers to start with here.

[Dennis Handly]

>I think is it hard to put gdb on that platform as it is production.

>Only option left is to debug the core file. Please can you suggest some pointers to start with here.

It will be harder to explain how to look at machine code and raw memory than it is to use gdb.

See my comments here:

http://h30499.www3.hp.com/t5/Languages-and-Scripting/Bus-Error-on-HP-Ux-PARISC/m-p/5422881/

Do you have a packcore of the abort?  Or are you debugging on the customer's system?

[prabhakarbhatt]

Hi Dennis,

Thanks for your input. Yes we have already requested for the packcore. So may take a day or 2 get from the customer. Need to ur valuable inputs once we start into debugging the core. :)

[Dennis Handly]

>Need your valuable inputs once we start into debugging the core.

The first thing to do is find the address of the memory being freed.  This should be in $r32 in frames 3, 2 and 1.  Make sure you check to make sure they match.  It is possible that the register was reused in one of the frames.

Once you do get the memory address, you should look at the contents to see if it matches what is being freed and to see if the previous memory region overwrote it:

(gdb) x /80wx address - 8*8

(gdb) x /20s address - 8*8

Before each region is a header.  The header contains a pointer to the previous block and a length of the current block.  The low order bits are flags.  If this pointer or length is overwritten, then you have these aborts.

Also, dumping the registers and disassembling the instructions around the abort would help:

(gdb) bt

(gdb) info reg

(gdb) disas $pc-16*12 $pc+16*4

You might also want to try a small test program and corrupt the heap and see what you get.