wanted: controlling backtrace output when using --disable-debugger

[Eric Tsung]

Feature request. *FEATURES*

Would like to control how the amount of BACKTRACE displayed when using --disable-debugger.

Looks like could add a global to debugger-disabled-hook in debug.lisp, at the line
(sb!debug:backtrace 128 *error-output*)
changing 128 to that global.

This code was found in sbcl-1.0.51, at src/code/debug.lisp.

Something a bit harder is to have some control in the output of each frame, i.e
((FAST-METHOD MYFUNCTION-WITH-LONG-LIST '(1 2 3 4 5 6 7 . . . 999999 1000000))
There's usefulness is displaying everything, but I think there is also usefulness in limiting this, especially for arguments that have very long lists/arrays/sequences, etc.

Linux [host] 2.6.18-238.el5 #1 SMP Thu Jan 13 15:51:15 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
Linux [host] 2.6.32-32-generic #62-Ubuntu SMP Wed Apr 20 21:52:38 UTC 2011 x86_64 GNU/Linux
SBCL 1.0.29.11.debian and SBCL 1.0.51

[Attila Lendvai (attila-lendvai)]

please note that i have two pending patches regarding backtraces, and one of them is cleaning up what happens when --disable-debugger

http://dwim.hu/gitweb/gitweb.cgi?p=sbcl;a=commitdiff;h=2c24babe86fc8ad5ebe1ab2f8a62f2dec742f731

afaik, Nikodemus is working on the integration of my frame cleaning patch, but it's not in master yet.

in my debugger patch, there a global called *default-backtrace-size-limit*.

[Eric Tsung (eftsung)]

Thanks for looking into this.

I was thinking about this more, and perhaps
--disable-debugger
could take an optional positive fixnum argument that would set the backtrace count value. The default could be
*default-backtrace-size-limit*

For the second part of this, having more fine grain control of the output of each frame is actually a more general problem of what to do display wise when some of the arguments are very long.

An analogous issue to this how describe used to work:
CL-USER> (defvar *my-very-long-list* (make-list 1000))
*MY-VERY-LONG-LIST*

SBCL 1.0.29.11.debian
CL-USER> (describe *my-very-long-list*)
(NIL NIL NIL NIL NIL NIL NIL NIL NIL
[Lots of other NILs] NIL)
is a CONS.

 SBCL 1.0.51
* (describe *MY-VERY-LONG-LIST*)

(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL..
  [list]

So perhaps logic in "describe" could be used here.

Going further with this (using 1.0.51)
$ sbcl --disable-debugger
This is SBCL 1.0.51, an implementation of ANSI Common Lisp.
. . .

* (defvar *my-very-long-list* (make-list 1000))

*MY-VERY-LONG-LIST*
* (defun my-bad-function (arg)
   (+ (car arg) (second arg)))

MY-BAD-FUNCTION
* (my-bad-function *my-very-long-list*)

Results in long output in frame 7:
7: (MY-BAD-FUNCTION
    (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL
     NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL
. . .
     NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))

[Attila Lendvai (attila-lendvai)]

re long lists in backtraces: you can set/bind *print-length* and *print-depth*, but also note https://bugs.launchpad.net/sbcl/+bug/758168

[Eric Tsung (eftsung)]

Yup (setq *print-length* ##) does the trick. FYI, *print-depth* is not yet defined as of 1.0.51.

Hmm, *print-depth* and *default-backtrace-size-limit*, seem to represent the same concept, just the later is more specific.

[Attila Lendvai (attila-lendvai)]

no, that's *print-level*, sorry

CLHS is your friend when your consultant's memory fails him in the age of fuzzy completion... :)