The value of a variable may be unavailable to the debugger in portions of the program where Lisp says that the variable is defined. If a variable value is not available, the debugger will not let you read or write that variable. With one exception, the debugger will never display an incorrect value for a variable. Rather than displaying incorrect values, the debugger tells you the value is unavailable.
The one exception is this: if you interrupt (e.g., with <C-c>) or if there is an unexpected hardware error such as “‘bus error’” (which should only happen in unsafe code), then the values displayed for arguments to the interrupted frame might be incorrect.1 This exception applies only to the interrupted frame: any frame farther down the stack will be fine.
The value of a variable may be unavailable for these reasons:
debug
optimization quality may have omitted debug
information needed to determine whether the variable is available.
Unless a variable is an argument, its value will only be available when
debug
is at least 2
.
debug
optimization quality is 3
.
debug
optimization quality is 3
.
compilation-speed
optimization quality, but most
source-level optimizations are done under all compilation policies.
(LET ((var1 var2)) ...)
In this case, var1
is substituted with var2
.
Since it is especially useful to be able to get the arguments to a
function, argument variables are treated specially when the
speed
optimization quality is less than 3
and the
debug
quality is at least 1
. With this compilation
policy, the values of argument variables are almost always available
everywhere in the function, even at unknown locations. For
non-argument variables, debug
must be at least 2
for
values to be available, and even then, values are only available at
known locations.
[1] Since the location of an interrupt or hardware error will always be an unknown location, non-argument variable values will never be available in the interrupted frame. See Unknown Locations and Interrupts.