Next: Debug Tail Recursion, Previous: Function Names, Up: Stack Frames [Contents][Index]
Sometimes the evaluator introduces new functions that are used to implement a user function, but are not directly specified in the source. The main place this is done is for checking argument type and syntax. Usually these functions do their thing and then go away, and thus are not seen on the stack in the debugger. But when you get some sort of error during lambda-list processing, you end up in the debugger on one of these funny frames.
These funny frames are flagged by printing “[
keyword]
” after the
parentheses. For example, this call:
(car 'a 'b)
will look like this:
(CAR 2 A) [:EXTERNAL]
And this call:
(string-upcase "test case" :end)
would look like this:
("DEFUN STRING-UPCASE" "test case" 335544424 1) [:OPTIONAL]
As you can see, these frames have only a vague resemblance to the original call. Fortunately, the error message displayed when you enter the debugger will usually tell you what problem is (in these cases, too many arguments and odd keyword arguments.) Also, if you go down the stack to the frame for the calling function, you can display the original source (see source-locations.)
With recursive or block compiled functions
(see block-compilation), an :EXTERNAL
frame may appear
before the frame representing the first call to the recursive function
or entry to the compiled block. This is a consequence of the way the
compiler does block compilation: there is nothing odd with your
program. You will also see :CLEANUP
frames during the execution
of unwind-protect
cleanup code. Note that inline expansion and
open-coding affect what frames are present in the debugger, see
sections debugger-policy and open-coding.
Next: Debug Tail Recursion, Previous: Function Names, Up: Stack Frames [Contents][Index]