I am debugging a runtime crash, with a stack trace that seems corrupted (see a related question from yesterday: Is the stack corrupted if the EBP frame pointer is NULL?).
Despite the corruption of the stack, I see many values on the stack that point to the exact locations of functions in the corresponding .map file. Furthermore, these functions are (for the most part, if not entirely) the expected functions that should appear on the stack in this case.
As one example (there are many), here is the stack value, and corresponding .map entry value:
0588fe5c: 005caa30 (stack address / value at that address)
0001:001c9a30 __ehhandler$?ProcessTAFRequest@TQueryThread@@UAEXXZ 005caa30 f portable_source:UQueryThread.obj
(.map file entry indicating that address 005caa30 is the starting location of the function noted)
Assuming (likely incorrectly) that the stack is not corrupted except near the top, and that the function addresses I see somehow do correspond to the stack frames and corresponding EIP (return address) pointers, then my question is this: Why do I consistently see the exact value of the location of the functions in the .map file corresponding to the stack? In the past, a number of times I have walked through an uncorrupted stack trace, and always, the EIP pointers in the stack frames point near, but not at, the location of the corresponding functions listed in the .map file. (This makes sense, since the return address will typically be in the middle of a function, not at the start).
Can somebody please shed light?
