[ clisp-Bugs-1538436 ] Internal Error: statement in file "debug.d", line 1149

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1538436, was opened at 2006-08-11 00:10
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1538436&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Smith (ansonyumo)
Assigned to: Bruno Haible (haible)
Summary: Internal Error: statement in file "debug.d", line 1149

Initial Comment:
Hi,

I was playing around with clisp 2.39 on cygwin tonight
and hit an internal error. It asked me to notify the
authors, so here goes. I eventually narrowed the
problem down to this set of repeatable steps:

[1]> (set 'a '(eval b))
(EVAL B)
[2]> set 'b '(eval a)

*** - EVAL: variable SET has no value
The following restarts are available:
USE-VALUE      :R1      You may input a value to be
used instead of SET.
STORE-VALUE    :R2      You may input a new value for SET.
ABORT          :R3      ABORT
Break 1 [3]> exit

*** - EVAL: variable EXIT has no value
The following restarts are available:
USE-VALUE      :R1      You may input a value to be
used instead of EXIT.
STORE-VALUE    :R2      You may input a new value for EXIT.
ABORT          :R3      ABORT
ABORT          :R4      ABORT
Break 2 [4]> quit
[5]> (set 'b '(eval a))
(EVAL A)
[6]> (eval a)

*** - Program stack overflow. RESET

*** - Internal error: statement in file "debug.d", line
1149 has been
      reached!!
      Please send the authors of the program a
description how you produced
      this error!
Break 1 [7]>

----------------------------------------------------------------------

>Comment By: Sam Steingold (sds)
Date: 2006-11-06 17:58

Message:
Logged In: YES 
user_id=5735

>Breakpoint 1, top_of_back_trace_frame (bt=0x226500) at
debug.d:1112
>1112    global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *bt) {
>(gdb) p fun
>$1 = (object) 0x226874
>(gdb) xout fun
>#<huh?! address=0x226874>(void *) 0x226874

fun is a local (auto) variable in top_of_back_trace_frame,
is has not been initialized yet.

----------------------------------------------------------------------

Comment By: szergling (szergling)
Date: 2006-11-06 00:06

Message:
Logged In: YES 
user_id=1630354

Following on from
https://sourceforge.net/tracker/index.php?func=detail&aid=1584890&group_id=1355&atid=101355,
, an investigation of the problem with gdb.

[2]> set 'b '(eval a)

*** - EVAL: variable SET has no value
The following restarts are available:
USE-VALUE      :R1      You may input a value to be used
instead of SET.
STORE-VALUE    :R2      You may input a new value for SET.
ABORT          :R3      ABORT
Break 1 [3]> exit

*** - EVAL: variable EXIT has no value
The following restarts are available:
USE-VALUE      :R1      You may input a value to be used
instead of EXIT.
STORE-VALUE    :R2      You may input a new value for EXIT.
ABORT          :R3      ABORT
ABORT          :R4      ABORT
Break 2 [4]> quit

Breakpoint 1, top_of_back_trace_frame (bt=0x226500) at
debug.d:1112
1112    global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) p fun
$1 = (object) 0x226874
(gdb) xout fun
#<huh?! address=0x226874>(void *) 0x226874
(gdb) zout fun
#<ADDRESS #x00226874>
(void *) 0x226874
(gdb) (set 'b '(eval a))
Undefined command: "".  Try "help".
(gdb) c
Continuing.

Breakpoint 1, top_of_back_trace_frame (bt=0x2265a0) at
debug.d:1112
1112    global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) c
Continuing.

Breakpoint 1, top_of_back_trace_frame (bt=0x226700) at
debug.d:1112
1112    global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) c
Continuing.

Breakpoint 1, top_of_back_trace_frame (bt=0x226760) at
debug.d:1112
1112    global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) s 50000

Breakpoint 1, top_of_back_trace_frame (bt=0x226a70) at
debug.d:1112
1112    global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) s 50000
[5]> (set 'b '(eval a))
(EVAL A)
[6]> (eval a)

Program received signal SIGSEGV, Segmentation fault.
eval (form=0x10161389) at eval.d:2891
2891          var gcv_object_t* top_of_frame = STACK; #
Pointer to Frame
(gdb) p top_of_frame
$2 = (gcv_object_t *) 0x0
(gdb)

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2006-10-26 09:07

Message:
Logged In: YES 
user_id=5735

may be related to
https://sourceforge.net/tracker/index.php?func=detail&aid=1584890&group_id=1355&atid=101355

----------------------------------------------------------------------

Comment By: Reini Urban (rurban)
Date: 2006-08-12 08:45

Message:
Logged In: YES 
user_id=13755

After blowing up the stack inside the debugger I inspected
the bt->bt_stack and bt->bt_function with gdb:

stackptr=0x7c9232f8, funcptr=0x7c91e3ed 

(gdb) x 0x7c9232f8
0x7c9232f8 <ntdll!CsrProbeForWrite+87>: 0x850ffb3b
(gdb) x 0x7c91e3ed
0x7c91e3ed <ntdll!ZwRequestWaitReplyPort+12>:   0x90000cc2 

backtrace broken.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2006-08-11 16:10

Message:
Logged In: YES 
user_id=5735

Brian, your bug report is appreciated.
please do not overreact.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2006-08-11 16:07

Message:
Logged In: YES 
user_id=5735

the internal error, if reproducible, should be fixed even if
it is arrived at by a user blunder.

----------------------------------------------------------------------

Comment By: Brian Smith (ansonyumo)
Date: 2006-08-11 16:05

Message:
Logged In: YES 
user_id=46488

OK, from the responses I have received from you guys it is
apparent that I should have fully qualified the error report
and my user profile.

1) I am not reporting any undesirable behavior, except for
the Internal Error.

2) I am not offering up these LISP statements up as an
example of anything useful. I whittled down the use case
into as small a set of steps as possible in order to help
you guys reproduce the error.

3) I am not a regular clisp user. This bug was found after
playing with clisp for about 10 minutes.

4) I am reporting this bug out of the goodness of my heart.
It does not matter to me whether you fix it.

5) Lastly, I am not an idiot. Please stop treating me as
such. If you would carefully read my original report, I was
only reporting the "Internal Error". I made no complaint
about the REPL not accepting my bad s-expressions or the
overflow. These were merely included to, as requested by the
clisp error message, describe how I got the machine into the
undesirable state.

Apologies for the flames, but my frustration level has
peaked. In the future, I will just ignore any requests from
clisp for help. Thank you. I have learned my lesson.

----------------------------------------------------------------------

Comment By: Reini Urban (rurban)
Date: 2006-08-11 15:41

Message:
Logged In: YES 
user_id=13755

[1]> (set 'a '(eval b))
(EVAL B)
[2]> set 'b '(eval a)

I hope you ARE aware the the original error is from the
missing brackets in [2].

I don't know if you get to the point where you infinitly
recurse into (eval a) => eval b) => (eval a) ... statements,
which in every language would blow up either the stack or
the heap or even might freeze the system.
Thanks for your report though. 

In my opinion it can be closed. 
After the great message 
"*** - Program stack overflow. RESET", 
do we want to fix the symptom in debug.d?

-- reini urban - cygwin maintainer of clisp

----------------------------------------------------------------------

Comment By: Brian Smith (ansonyumo)
Date: 2006-08-11 13:22

Message:
Logged In: YES 
user_id=46488

Look, I'm just trying to be a good citizen. clisp asked me
to report the error and I did. 

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2006-08-11 12:45

Message:
Logged In: YES 
user_id=5735

I followed your example step-by-step on linux 
and I did not see the internal error.
clisp developers do not have access to cygwin.
it is up to you to do the debugging.

----------------------------------------------------------------------

Comment By: Brian Smith (ansonyumo)
Date: 2006-08-11 12:28

Message:
Logged In: YES 
user_id=46488

I realize that the overflow is expected, that was the goal
of the experiment. The "Internal error" was the issue I
reported.

If I do this on clisp 2.38/cygwin, I get a segmentation
fault. 2.39 is a little better, in that it just reports an
Internal Error.

You have to do the exact set of steps I did, including the
illegal statements.

I would debug it if I knew more about clisp, but
unfortunately for all those involved I'm just toying with it.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2006-08-11 11:34

Message:
Logged In: YES 
user_id=5735

"Program stack overflow. RESET" is to be expected (you are
doing infinite recursion).
i cannot reproduce "Internal error" though - could you
please try to debug it? 
set a break in top_of_back_trace_frame and use "xout" or
"zout" to print the valus of "fun".
see http://clisp.cons.org/impnotes/faq.html#faq-debug

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1538436&group_id=1355