Core dump (heap corruption)

[prabhakarbhatt]

Dennis,

Please find the data which u asked for the frame 0 below:

(gdb) x /8gx $r33-8*2
0x600000010d5518a8:     0x0000000000000000      0x600000010f2c3728
0x600000010d5518b8:     0x0000000000000440      0x000000000f0fff00
0x600000010d5518c8:     0x0000000000000000      0x0000000000000000
0x600000010d5518d8:     0x0000000000000000      0x000100000000476d
(gdb) x /20s $r33-8*2
0x600000010d5518a8:      ""
0x600000010d5518a9:      ""
0x600000010d5518aa:      ""
0x600000010d5518ab:      ""
0x600000010d5518ac:      ""
0x600000010d5518ad:      ""
0x600000010d5518ae:      ""
0x600000010d5518af:      ""
0x600000010d5518b0:      "`"
0x600000010d5518b2:      ""
0x600000010d5518b3:      "\001\017,7("
0x600000010d5518b9:      ""
0x600000010d5518ba:      ""
0x600000010d5518bb:      ""
0x600000010d5518bc:      ""
0x600000010d5518bd:      ""
0x600000010d5518be:      "\004@"
0x600000010d5518c1:      ""
0x600000010d5518c2:      ""
0x600000010d5518c3:      ""
(gdb) x /gx $gr33
0x600000010d5518b8:     0x0000000000000440
(gdb)

[Dennis Handly]

(gdb) x /8gx $r33-8*2
0x600000010d5518a8:     0x0000000000000000      0x600000010f2c3728
0x600000010d5518b8:     0x0000000000000440<    0x000000000f0fff00
0x600000010d5518c8:     0x0000000000000000  f>  0x0000000000000000
0x600000010d5518d8:     0x0000000000000000 da> 0x000100000000476d

That 0440 is where that bad value comes from.  Not sure how it was overwritten.

Here is where you need a watchpoint and rerun it.

[prabhakarbhatt]

Hi Dennis,

Thanks for the reply. Please can you clarify my following querries.

1. How to decide that (gdb) x /8gx $r33-8*2
0x600000010d5518a8:     0x0000000000000000      0x600000010f2c3728
0x600000010d5518b8:     0x0000000000000440<    0x000000000f0fff00
0x600000010d5518c8:     0x0000000000000000      0x0000000000000000
0x600000010d5518d8:     0x0000000000000000      0x000100000000476d

0x0000000000000440< is invalid? any specific format

2. means  value of "0x0000000000000440", which we are trying to free?

2. It means here no double deletion is happening?

3. This value woud have overwritten by our application or any chances that from outside source/slibary can also cause this. pls can u tell me wha twould have been the causes of this.

4. Here is where you need a watchpoint and rerun it. -------> rerun the gdb  on core or run in production platform????

Thanks a lot for your help.

[Dennis Handly]

>1. How to decide that (gdb) x /8gx $r33-8*2

This includes the $r33 value and backwards and forwards to see if writing beyond the heap block.

There is no string of ascii bytes.

>2. means value of "0x0000000000000440", which we are trying to free?

No, this should be the link to the previous block.

>2. It means here no double deletion is happening?

Can't tell.

>3. This value would have overwritten by our application or any chances that from outside source/shlib can also cause this.

You have to set a watchpoint and run the program to see who is changing that address.  I thought if the previous block was gone beyond the end by just one byte, that 0x00 would overwrite the 0x60 for the heap address.

Strangely, when I try a simple heap allocation, I don't get that alignment, I get:

$ a.out

6000000000004010: 0000000000000000, 0000000000000000
6000000000004020: 0000000000000000, 0000000000000000
6000000000004030: 6000000000000070, 000000000f0fff01  (pointer to previous block and length words)
6000000000004040: >ffffffffffffffff   (heap block starts here)

So I only see 16 bytes of heap block overhead.

[prabhakarbhatt]

Hi Dennis,

Thanks for the info.

1. 0x600000010d5518a8:     0x0000000000000000      0x600000010f2c3728
0x600000010d5518b8:     0x0000000000000440<    0x000000000f0fff00
0x600000010d5518c8:     0x0000000000000000      0x0000000000000000
0x600000010d5518d8:     0x0000000000000000      0x000100000000476d

[Prabhakar] What I understood by ur explanation is 0x0000000000000440 this previous block aadress is not correct.  Is my understanding correct.

2. You have to set a watchpoint and run the program to see who is changing that address.  I thought if the previous block was gone beyond the end by just one byte, that 0x00 would overwrite the 0x60 for the heap address.

[Prabhakar] This should be done run time or can be run using core file?

[Dennis Handly]

>1. 0x600000010d5518a8:  0x0000000000000000      0x600000010f2c3728
0x600000010d5518b8:     0x0000000000000440<    0x000000000f0fff00
0x600000010d5518c8:     0x0000000000000000      0x0000000000000000
[Prabhakar] What I understood by your explanation is 0x0000000000000440 this previous block address is not correct.

Yes.  Or the heap address was already freed then reallocated or or bad heap address.

>2. You have to set a watchpoint and run the program
>[Prabhakar] This should be done run time or can be run using core file?

Watchpoints and breakpoints require moving the PC.