2

My understanding of stack traces is essentially based on What is exactly the base pointer and stack pointer? To what do they point?.

A program I have been helping to develop for years spits out a stack dump when it crashes, and I have become accustomed to evaluating these stack traces, in correspondence with a .map file that the C++ compiler produces. A number of times, I have successfully been able to walk the stack and debug issues.

However, sometimes the stack trace has a NULL EBP (frame) pointer. Here is the relevant snippet from such a sample stack dump:

Initial EBP pointer value: 04d8fab0
{at address 04d8fab0: 00000000}

As you can see, the value of the EBP frame pointer is NULL. Therefore, I cannot walk the stack.

Is this the sign of a corrupted stack, or is there another possible explanation?

Community
  • 1
  • 1
Dan Nissenbaum
  • 13,558
  • 21
  • 105
  • 181
  • Are you building with optimizations? Sometimes compilers will use `%ebp` as a general purpose register to give it an extra reg to work with... at the cost of making it pretty much impossible to trace the stack. Most compilers also have an option to disable this behavior. – FatalError May 02 '12 at 19:29
  • Which compiler and compilation flags are you using? – Neil May 02 '12 at 19:52
  • 1
    In Visual Studio, the option `Omit Frame Pointers` is set to `No` (in release, as well as debug mode). Indeed, in many stack traces, the frame pointers are valid. Is it possible that it's a coincidence that the frame pointers are sometimes valid, and that `Omit Frame Pointers` does not do what I expect? – Dan Nissenbaum May 02 '12 at 19:55
  • 1
    It might be because a buffer overflow has written zeroes over the stack frame. That would both cause a crash and make it impossible to walk the stack. – Harry Johnston May 02 '12 at 21:38
  • Agreed. If that is the only possible explanation, then it would mean that my question, "is the stack corrupted if the frame pointer is NULL", would have "yes" as the answer. – Dan Nissenbaum May 02 '12 at 21:39
  • Compare ESP to EBP. If they point to the same part of memory, then it is extremely likely that the stack is corrupted. If they point to completely different parts of memory, EBP is probably being used for something else. The value of the instruction pointer might also be of interest. – Harry Johnston May 03 '12 at 02:39
  • Indeed, ESP and EBP point to almost the same spot in memory. ESP points to `04d8f648`. EBP points to `04d8fab0`. Thanks for the heads up. However, doesn't EBP typically point to a place within the stack (therefore, near where ESP points)? In fact, that's how I have been walking the stack - walking along the locations pointed to by the frame pointers, with the first pointed to by EBP. – Dan Nissenbaum May 03 '12 at 02:42

1 Answers1

1

As you can see, the value of the EBP frame pointer is NULL. Therefore, I cannot walk the stack. Is this the sign of a corrupted stack, or is there another possible explanation?

I think there is another explanation, rooted in the fact that in addition to holding the address of the current stack frame, the EBP register can also be used for any other purpose like general-purpose registers. In order to do that safely, two things are required:

  1. Store its current content to the stack by calling

    PUSH EBP

  2. Restore the content after the general-purpose usage and before exiting the current procedue by calling

    POP EBP

So I was thinking the case you were experiencing was not necessarily caused by corruption of the stack, as it technically may have been that the dump was generated while the EBP register was temporarily being used for general-purpose usage by someplace else in the process' code, maybe not even code you've written.

Geezer
  • 5,600
  • 18
  • 31
  • Interesting possibility. Do you know whether such behavior actually might happen, or is this purely a theoretical possibility as far as you know? – Dan Nissenbaum Sep 10 '13 at 16:40
  • You can do a disassembly of the code and check if ebp is used for any other purpose ? – Haswell Feb 04 '21 at 16:18