When I do a stack trace direct in clisp (win32 version 2.33.1) after a
particular simple error occurs, I get a stack trace with 71 stack frames.
In slime I only get the two top most frames.
Also in slime I don't see the parameter values of the functions calls.
A known problem? Or a user error?
Rene.
"Rene de Visser" <··············@hotmail.de> writes:
> When I do a stack trace direct in clisp (win32 version 2.33.1) after a
> particular simple error occurs, I get a stack trace with 71 stack frames.
>
> In slime I only get the two top most frames.
>
> Also in slime I don't see the parameter values of the functions calls.
>
> A known problem? Or a user error?
Slime adds frames when you move the cursor down the backtrace.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
"Pascal Bourguignon" <····@mouse-potato.com> wrote in message
···················@thalassa.informatimago.com...
> "Rene de Visser" <··············@hotmail.de> writes:
>
> > When I do a stack trace direct in clisp (win32 version 2.33.1) after a
> > particular simple error occurs, I get a stack trace with 71 stack
frames.
> >
> > In slime I only get the two top most frames.
> >
> > Also in slime I don't see the parameter values of the functions calls.
> >
> > A known problem? Or a user error?
>
> Slime adds frames when you move the cursor down the backtrace.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> The world will now reboot; don't bother saving your artefacts.
Not in this case I think. For starters I want to move up and not down.
I have a frame 0 which is (compile-file "...")
However if I execute outside of slime i have a further 71 stack frames above
this which show
where the error occured inside of (compile-file "...").
i.e. executing outside of slime (compile-file "...") is frame 71.
Its like slime has already unwound the stack to this point.
For example if I use 'B' to get to the normal clisp debugger, the frames
aren't there either.
Its like they have been unwound already.
It only works properly if I don't have slime running at all.
Maybe slime over-rides compile-file with its own version that has some bad
side effects for debugging?
Rene.
"Rene de Visser" <··············@hotmail.de> wrote in message
·················@news.sap-ag.de...
>
> For example if I use 'B' to get to the normal clisp debugger, the frames
> aren't there either.
Correction to that. They ARE there in the clisp debugger. Just for some
reason they don't show up in slime.
Rene.
"Rene de Visser" <··············@hotmail.de> writes:
> "Pascal Bourguignon" <····@mouse-potato.com> wrote in message
> ···················@thalassa.informatimago.com...
> > "Rene de Visser" <··············@hotmail.de> writes:
> >
> > > When I do a stack trace direct in clisp (win32 version 2.33.1) after a
> > > particular simple error occurs, I get a stack trace with 71 stack
> frames.
> > >
> > > In slime I only get the two top most frames.
> > >
> > > Also in slime I don't see the parameter values of the functions calls.
> > >
> > > A known problem? Or a user error?
> >
> > Slime adds frames when you move the cursor down the backtrace.
> >
> > --
> > __Pascal Bourguignon__ http://www.informatimago.com/
> > The world will now reboot; don't bother saving your artefacts.
>
> Not in this case I think. For starters I want to move up and not down.
>
> I have a frame 0 which is (compile-file "...")
>
> However if I execute outside of slime i have a further 71 stack frames above
> this which show
> where the error occured inside of (compile-file "...").
>
> i.e. executing outside of slime (compile-file "...") is frame 71.
>
> Its like slime has already unwound the stack to this point.
>
> For example if I use 'B' to get to the normal clisp debugger, the frames
> aren't there either.
>
> Its like they have been unwound already.
>
> It only works properly if I don't have slime running at all.
>
> Maybe slime over-rides compile-file with its own version that has some bad
> side effects for debugging?
>
> Rene.
>
CLISP TEST> (defun fact (x) (if (= 0 x) (/ x 0) (* x (fact (1- x)))))
FACT
CLISP TEST> (fact 4)
--> sldb:
division by zero
[Condition of type SYSTEM::SIMPLE-DIVISION-BY-ZERO]
Restarts:
0: [ABORT] Abort handling SLIME request.
Backtrace:
0: frame binding variables (~ = dynamically):
| ~ SYSTEM::*FASOUTPUT-STREAM* <--> NIL
1: EVAL frame for form (/ X 0)
2: EVAL frame for form (IF (= 0 X) (/ X 0) (* X (FACT (1- X))))
3: APPLY frame for call (FACT '0)
4: EVAL frame for form (FACT (1- X))
5: EVAL frame for form (* X (FACT (1- X)))
6: EVAL frame for form (IF (= 0 X) (/ X 0) (* X (FACT (1- X))))
7: APPLY frame for call (FACT '1)
8: EVAL frame for form (FACT (1- X))
9: EVAL frame for form (* X (FACT (1- X)))
10: EVAL frame for form (IF (= 0 X) (/ X 0) (* X (FACT (1- X))))
11: APPLY frame for call (FACT '2)
12: EVAL frame for form (FACT (1- X))
13: EVAL frame for form (* X (FACT (1- X)))
14: EVAL frame for form (IF (= 0 X) (/ X 0) (* X (FACT (1- X))))
15: APPLY frame for call (FACT '3)
16: EVAL frame for form (FACT (1- X))
17: EVAL frame for form (* X (FACT (1- X)))
18: EVAL frame for form (IF (= 0 X) (/ X 0) (* X (FACT (1- X))))
19: APPLY frame for call (FACT '4)
20: EVAL frame for form (FACT 4)
21: EVAL frame for form (SWANK:LISTENER-EVAL "(fact 4)
")
22: EVAL frame for form (SWANK:START-SERVER "/tmp/slime.22876")
23: EVAL frame for form (SWANK:START-SERVER "/tmp/slime.22876")
CLISP TEST> (compile 'fact)
--> sldb (during compilation):
division by zero
[Condition of type SYSTEM::SIMPLE-DIVISION-BY-ZERO]
Restarts:
0: [ABORT] Abort handling SLIME request.
Backtrace:
0: frame binding variables (~ = dynamically):
| ~ SYSTEM::*FASOUTPUT-STREAM* <--> NIL
1: EVAL frame for form (COMPILE 'FACT)
2: EVAL frame for form (SWANK:LISTENER-EVAL "(compile 'fact)
")
3: EVAL frame for form (SWANK:START-SERVER "/tmp/slime.22876")
4: EVAL frame for form (SWANK:START-SERVER "/tmp/slime.22876")
CLISP TEST> (defun fact (x) (if (= 0 x) (/ x *var*) (* x (fact (1- x)))))
FACT
CLISP TEST> (compile 'fact)
WARNING in FACT :
*VAR* is neither declared nor bound,
it will be treated as if it were declared SPECIAL.
FACT
1
1
CLISP TEST> (defvar *var* 0)
*VAR*
CLISP TEST> (fact 4)
--> sldb:
division by zero
[Condition of type SYSTEM::SIMPLE-DIVISION-BY-ZERO]
Restarts:
0: [ABORT] Abort handling SLIME request.
Backtrace:
0: frame binding variables (~ = dynamically):
| ~ SYSTEM::*FASOUTPUT-STREAM* <--> NIL
1: EVAL frame for form (FACT 4)
2: EVAL frame for form (SWANK:LISTENER-EVAL "(fact 4)
")
3: EVAL frame for form (SWANK:START-SERVER "/tmp/slime.22876")
4: EVAL frame for form (SWANK:START-SERVER "/tmp/slime.22876")
So, is that this difference between the first backtrace and this later
backtrace you're complaining about? It does not depend on slime, it's
the way clisp works. It has simplified tail-recursion (and can simply
some other tail-calls and other stack frames) in compiled code.
Even if you go back to the clisp debugger, the interperter backtrace
is more informative than the compiled backtrace:
interpreted:
*** - division by zero
The following restarts are available:
ABORT :R1 Abort handling SLIME request.
Break 1 [3]> :bt
<1> #<SYSTEM-FUNCTION EXT:SHOW-STACK>
<2> #<COMPILED-CLOSURE SYSTEM::DEBUG-BACKTRACE>
<3> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT>
<4> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP-2-1>
<5> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS>
<6> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP-2>
<7> #<SYSTEM-FUNCTION SYSTEM::DRIVER>
<8> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP>
<9> #<SYSTEM-FUNCTION INVOKE-DEBUGGER>
<10> #<SYSTEM-FUNCTION /> 1
<11> #<SPECIAL-OPERATOR IF>
EVAL frame for form (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X))))
APPLY frame for call (FACT '0)
EVAL frame for form (FACT (1- X))
<12>
#<CLOSURE FACT (X) (DECLARE (SYSTEM::IN-DEFUN FACT))
(BLOCK FACT (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X)))))> 1
EVAL frame for form (* X (FACT (1- X)))
<13> #<SPECIAL-OPERATOR IF>
EVAL frame for form (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X))))
APPLY frame for call (FACT '1)
EVAL frame for form (FACT (1- X))
<14>
#<CLOSURE FACT (X) (DECLARE (SYSTEM::IN-DEFUN FACT))
(BLOCK FACT (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X)))))> 1
EVAL frame for form (* X (FACT (1- X)))
<15> #<SPECIAL-OPERATOR IF>
EVAL frame for form (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X))))
APPLY frame for call (FACT '2)
EVAL frame for form (FACT (1- X))
<16>
#<CLOSURE FACT (X) (DECLARE (SYSTEM::IN-DEFUN FACT))
(BLOCK FACT (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X)))))> 1
EVAL frame for form (* X (FACT (1- X)))
<17> #<SPECIAL-OPERATOR IF>
EVAL frame for form (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X))))
APPLY frame for call (FACT '3)
EVAL frame for form (FACT (1- X))
<18>
#<CLOSURE FACT (X) (DECLARE (SYSTEM::IN-DEFUN FACT))
(BLOCK FACT (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X)))))> 1
EVAL frame for form (* X (FACT (1- X)))
<19> #<SPECIAL-OPERATOR IF>
EVAL frame for form (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X))))
APPLY frame for call (FACT '4)
EVAL frame for form (FACT 4)
<20>
#<CLOSURE FACT (X) (DECLARE (SYSTEM::IN-DEFUN FACT))
(BLOCK FACT (IF (= 0 X) (/ X *VAR*) (* X (FACT (1- X)))))> 1
EVAL frame for form
(SWANK:LISTENER-EVAL
"(fact 4)
")
<21> #<SYSTEM-FUNCTION EVAL>
<22> #<COMPILED-CLOSURE SWANK::EVAL-REGION>
<23> #<COMPILED-CLOSURE SWANK::LISTENER-EVAL-1>
<24> #<COMPILED-CLOSURE #:|(DEFINTERFACE CALL-WITH-SYNTAX-HOOKS (FN) ...)-29-3-1-1|>
<25> #<GENERIC-FUNCTION SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS>
<26> #<COMPILED-CLOSURE SWANK:LISTENER-EVAL>
EVAL frame for form (SWANK:START-SERVER "/tmp/slime.22876")
<27> #<SYSTEM-FUNCTION EVAL>
<28> #<COMPILED-CLOSURE SWANK::EVAL-FOR-EMACS>
<29> #<SYSTEM-FUNCTION FUNCALL> 3
<30> #<COMPILED-CLOSURE SWANK::READ-FROM-EMACS>
<31> #<COMPILED-CLOSURE SWANK::HANDLE-REQUEST-3>
<32> #<COMPILED-CLOSURE SWANK::CALL-WITH-REDIRECTED-IO>
<33> #<COMPILED-CLOSURE SWANK::HANDLE-REQUEST>
<34> #<COMPILED-CLOSURE SWANK::SIMPLE-SERVE-REQUESTS>
<35> #<COMPILED-CLOSURE SWANK::SERVE-REQUESTS>
<36> #<COMPILED-CLOSURE SWANK::SERVE-CONNECTION>
<37> #<COMPILED-CLOSURE SWANK::SETUP-SERVER>
<38> #<COMPILED-CLOSURE SWANK:START-SERVER>
Printed 38 frames
Break 1 [3]>
compiled:
*** - division by zero
The following restarts are available:
ABORT :R1 Abort handling SLIME request.
Break 1 TEST[4]> :bt
<1> #<SYSTEM-FUNCTION EXT:SHOW-STACK>
<2> #<COMPILED-CLOSURE SYSTEM::DEBUG-BACKTRACE>
<3> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT>
<4> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP-2-1>
<5> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS>
<6> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP-2>
<7> #<SYSTEM-FUNCTION SYSTEM::DRIVER>
<8> #<COMPILED-CLOSURE SYSTEM::BREAK-LOOP>
<9> #<SYSTEM-FUNCTION INVOKE-DEBUGGER>
<10> #<SYSTEM-FUNCTION /> 1
<11> #<COMPILED-CLOSURE FACT>
<12> #<COMPILED-CLOSURE FACT>
<13> #<COMPILED-CLOSURE FACT>
<14> #<COMPILED-CLOSURE FACT>
<15> #<COMPILED-CLOSURE FACT>
EVAL frame for form
(SWANK:LISTENER-EVAL
"(fact 4)
")
<16> #<SYSTEM-FUNCTION EVAL>
<17> #<COMPILED-CLOSURE SWANK::EVAL-REGION>
<18> #<COMPILED-CLOSURE SWANK::LISTENER-EVAL-1>
<19> #<COMPILED-CLOSURE #:|(DEFINTERFACE CALL-WITH-SYNTAX-HOOKS (FN) ...)-29-3-1-1|>
<20> #<GENERIC-FUNCTION SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS>
<21> #<COMPILED-CLOSURE SWANK:LISTENER-EVAL>
EVAL frame for form (SWANK:START-SERVER "/tmp/slime.22876")
<22> #<SYSTEM-FUNCTION EVAL>
<23> #<COMPILED-CLOSURE SWANK::EVAL-FOR-EMACS>
<24> #<SYSTEM-FUNCTION FUNCALL> 3
<25> #<COMPILED-CLOSURE SWANK::READ-FROM-EMACS>
<26> #<COMPILED-CLOSURE SWANK::HANDLE-REQUEST-3>
<27> #<COMPILED-CLOSURE SWANK::CALL-WITH-REDIRECTED-IO>
<28> #<COMPILED-CLOSURE SWANK::HANDLE-REQUEST>
<29> #<COMPILED-CLOSURE SWANK::SIMPLE-SERVE-REQUESTS>
<30> #<COMPILED-CLOSURE SWANK::SERVE-REQUESTS>
<31> #<COMPILED-CLOSURE SWANK::SERVE-CONNECTION>
<32> #<COMPILED-CLOSURE SWANK::SETUP-SERVER>
<33> #<COMPILED-CLOSURE SWANK:START-SERVER>
Printed 33 frames
Break 1 TEST[4]>
with 5 frames less.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
"Rene de Visser" <··············@hotmail.com> writes:
> So with :bt1 we have everything that slime has, plus about another 100
> frames extra...
>
> So it looks to me more than the difference between compile and interpreted
> code to me.
>
> In slime none of the frames that are of interest seem to be available, and I
> am not sure why.
Yes, that's a "known problem". It's also mentioned in the PROBLEMS
file. The reason is that CLISP has, AFAIK, no debugger interface for
compiled functions. All there is, is a function like "print the frame
and all local variables to a stream". That's not enough for SLIME.
And that function is written in C. (It's C-Lisp after all :) I once
tried to write a better interface, but understanding CLISP's C code is
beyond by capabilities.
The information to produce a useful backtrace is obviously there, but
it is not easily accessible from Lisp. Writing the code to make it
available would be a nice contribution.
Helmut.
"Helmut Eller" <········@stud3.tuwien.ac.at> wrote in message
···················@stud3.tuwien.ac.at...
> "Rene de Visser" <··············@hotmail.com> writes:
> Yes, that's a "known problem". It's also mentioned in the PROBLEMS
> file. The reason is that CLISP has, AFAIK, no debugger interface for
I had read the problems file.
It says "The backtrace for compiled functions is not very informative."
I had read this to say: The backtrace should be there, just not so
readable.
The problems file could be changed to say:
"The backtrace for compiled functions can not be displayed in some
situations."
>
> The information to produce a useful backtrace is obviously there, but
> it is not easily accessible from Lisp. Writing the code to make it
> available would be a nice contribution.
I don't normally use CLisp, so I'm not motivated to do this myself.
Rene.