1
votes

I have a Heap corruption crash for an application and so I turned on page heap from gflags and collected a crash dump file for that application.

From the dump file I found out that it is due to double freeing the memory.

Here is an example, From the call stack I found this

msvcr100!free(void * pBlock = "**Address**")

Then I did this

!heap -p -a <address>

address found in
_HEAP @ 
  HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
    Address 000a 0000  [02]   address    00003 - **(free )**
Trace: <1>
       <2>
       <3>

So we can see that it is trying to double free the memory and that resulted in crash. My question is can we see the call stack that changed or freed that memory before this operation? Is it possible?

I can see a trace below the !heap -p -a command is that the one that freed the memory? If it is so, I can see only some part of call stack, Is there any way I can see the total call stack or walk through the call stack manually to see which operation freed that block of memory.

2
You are asking for a time machine, a dump file doesn't have one. - Hans Passant
Yes, I have some knowledge that a dump file is snapshot at that point of time but just curious if enabling full page heap can give little more information than who is trying to free the memory like who already freed the memory? - user2800803
You should probably enable page heap to get yourself started - page heap use bit patterns to mark memory so corruptions (as double use) are easier to catch. Also, this link should be helpful: code.msdn.microsoft.com/windowsdesktop/… - deemok

2 Answers

1
votes

If you have the source code you can replace the delete/free functions with your own functions that can capture the stack just before the release actually happens.

On windows you can get the call stack using the function CaptureStackBackTrace however this functions returns a set of pointers and you need to translate them to symbol names. To do that you can use SymInitialize, then for each pointer you can use SymFromAddr to get the name of the symbol. The names are the actual functions that you are searching for.

However it would be easier to use a debugger on windows. There is also Application Verifier which is an application from microsoft that can help you capture heap corruptions (when used with the visual studio debugger).

Hope this helps Razvan.

0
votes

If you run the debug version, there is a fair chance that you will see more of the call stack.

See also this link