Previous: Debug Tail Recursion, Up: Stack Frames [Contents][Index]
The debugger operates using special debugging information attached to the compiled code. This debug information tells the debugger what it needs to know about the locations in the code where the debugger can be invoked. If the debugger somehow encounters a location not described in the debug information, then it is said to be unknown. If the code location for a frame is unknown, then some variables may be inaccessible, and the source location cannot be precisely displayed.
There are three reasons why a code location could be unknown:
debug
optimization quality. See debugger-policy.
^C.
bus error” occurred in code that was
compiled unsafely due to the value of the safety optimization
quality. See optimize-declaration.
In the last two cases, the values of argument variables are accessible, but may be incorrect. See debug-var-validity for more details on when variable values are accessible.
It is possible for an interrupt to happen when a function call or return is in progress. The debugger may then flame out with some obscure error or insist that the bottom of the stack has been reached, when the real problem is that the current stack frame can’t be located. If this happens, return from the interrupt and try again.
When running interpreted code, all locations should be known. However, an interrupt might catch some subfunction of the interpreter at an unknown location. In this case, you should be able to go up the stack a frame or two and reach an interpreted frame which can be debugged.
Previous: Debug Tail Recursion, Up: Stack Frames [Contents][Index]