You can get thrown into the Lisp debugger in several ways; for example if Lisp is interrupted, if a breakpoint was mistakenly left in the Nuprl code or if you hit a bug. The particular debugger appearance and commands given below are for Lucid Common Lisp. Other Lisps should be similar.
The initial message put out by the debugger should tell you what caused it to be invoked. To resume after an interrupt or breakpoint, enter:
To abort the current computation and restart, enter:
If you get a crash, you can get more information on it as follows. The initial crash message might look something like:
Here, the 
-> 
is the debugger prompt. Enter:
Lisp prints a backtrace. For example:
Enter:
2 or 3 times. For example:
This provides a bit more information on the last function calls. When you send in a bug report, include the error message, backtrace and function calls you have obtained as above. Also, mention briefly what you were doing at the time of the crash.
To recover from a crash, enter
at the debugger prompt. Lisp then prints a top level prompt. For example:
-> :a
> 
Try restarting by entering
If another crash follows immediately, the problem might be linked with
the window system interface. Enter 
:a
RETURN
to get back
to the top level, and then enter
On executing the (reset ) function, all the Nuprl windows will close and (nuprl) will open up an initial ML-Top-Loop and library window. Any proofs you were just working on will not have been lost. Use the view function to open them up again. However, you might have lost the contents of the last term-editor window you were working in.
If still the system crashes but you can execute functions in the ML Top Loop , try dumping any theories you haven't previously saved, quit
the Nuprl session, and start a new one (The quit function is (quit). If you can't even get the ML Top Loop running, the bug is very serious. Your only choice is to quit the session, losing any work you've done and haven't saved, and start a new session.