#374 Program stack overflow. RESET -> Internal error
Hi folks,
I met a problem the other day with some buggy code of
mine involving loop and tail-recursion. Here's the
reproducible problem:
[3]> (load "~/code/lisp/delme.lisp")
;; Loading file /cygdrive/c/home/code/lisp/delme.lisp ...
;; Loaded file /cygdrive/c/home/code/lisp/delme.lisp
T
...compile the function trace-outline...
[15]> (compiled-function-p #'trace-outline)
T
[16]> (trace-outline '(115 41))
*** - 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!
I can usually, but not always continue working after this.
My setups:
uname -a
CYGWIN_NT-5.1 mb6596 1.5.21(0.156/4/2) 2006-07-30 14:21
i686 Cygwin
CL-USER> (lisp-implementation-type)
"CLISP"
CL-USER> (lisp-implementation-version)
"2.39 (2006-07-16) (built 3367203258) (memory 3367203785)"
I have been able to reproduce this on a similar
pre-built cygwin clisp setup and without the full
linking set (all the same version). Here's the file I
used. Note that the code is *BUGGY*, and I have since
rewrote it to get the code to run. For context, I
provide that here. It was a quick hack to create an
ordered linked list of points around the boundary of an
image object, like chain codes.
(defparameter *coords* (list))
;; This works.
(defun trace-outline (start-coord)
(flet ((valid-step (c)
(and (= (apply #'aref *image* c) 1)
(not (equal (cadr *coords*) c)))))
(push start-coord *coords*)
(loop
for (row col) = (car *coords*)
do (loop
for c in `((,(1- row) ,col) (,(1+ row) ,col)
(,row ,(1- col)) (,row ,(1+ col)))
when (valid-step c)
do
(push c *coords*)
(return))
until (equal start-coord (car *coords*)))))
PS: It is not convenient to change the data *rows* or
*cols*, and since they're so small, it didn't matter -
I'm sending them verbatim. Additionally, using a global
counter, I counted more than 8000 iterations in the
loop tail-function-call bit before the stack error.
Please tell if I've screwed up anywhere, or missed out
anything. Thanks in advance.
Problem isolated into this file.
Logged In: YES
user_id=5735
may be related to
https://sourceforge.net/tracker/index.php?func=detail&aid=1538436&group_id=1355&atid=101355
Logged In: YES
user_id=1630354
Hi again, I've been busy, so I haven't had time to look into
this. Here's how far I got today when I tried to debug it.
It's a bit
verbose, but I've decided to include everything just to be
safe. top_of_back_trace_frame kept getting hit by the
breakpoint I
set, so I've stepped multiple times to get past them. Hope
that's ok?
The value of fun looked funny at first too. Later, it becomes
unprintable with xout/zout (reproducible). What should I do
next?
$ gdb a.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i686-pc-cygwin"...a.exe: No such
file or directory.
No symbol table is loaded. Use the "file" command.
/cygdrive/c/cygwin/home/clisp/build/.gdbinit:109: Error in
sourced command file:
No breakpoint number 0.
(gdb) base
(gdb) break top_of_back_trace_frame
Breakpoint 1 at 0x4aa033: file debug.d, line 1112.
(gdb) run
Starting program:
/cygdrive/c/cygwin/home/clisp/build/base/lisp.exe -B . -N loca
le -E 1:1 -q -norc -M base/lispinit.mem
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygcrypt-0.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/cygiconv-2.dll
Loaded symbols for /usr/bin/cygintl-3.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/ole32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/gdi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/user32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/msvcrt.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/oleaut32.dll
[1]> (progn (load "~/code/lisp/delme.lisp") (compile
'trace-outline))
;; Loading file /cygdrive/c/home/code/lisp/delme.lisp ...
Breakpoint 1, top_of_back_trace_frame (bt=0x225b70) at
debug.d:1112
1112 global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) zout fun
#<ADDRESS #x00225CB0>
(void *) 0x225cb0
(gdb) p fun
$1 = (object) 0x225cb0
(gdb) xout fun
#<huh?! address=0x225cb0>(void *) 0x225cb0
(gdb) c
Continuing.
Breakpoint 1, top_of_back_trace_frame (bt=0x225dc0) at
debug.d:1112
1112 global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) p fun
$2 = (object) 0x225cb0
(gdb) xout fun
#<huh?! address=0x225cb0>(void *) 0x225cb0
(gdb) zout fun
#<ADDRESS #x00225CB0>
(void *) 0x225cb0
(gdb) n 50000
Breakpoint 1, top_of_back_trace_frame (bt=0x225b70) at
debug.d:1112
1112 global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) n 50000
Breakpoint 1, top_of_back_trace_frame (bt=0x225dc0) 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=0x2258c0) at
debug.d:1112
1112 global gcv_object_t* top_of_back_trace_frame (const
struct backtrace_t *
bt) {
(gdb) s 50000
;; Loaded file /cygdrive/c/home/code/lisp/delme.lisp
TRACE-OUTLINE ;
NIL ;
NIL
[2]> (trace-outline '(115 41))
Program received signal SIGSEGV, Segmentation fault.
0x0042b512 in subscripts_to_index (array=0x10150eb5,
argptr=0x0, argcount=2,
index_=0x33020) at array.d:483
483 uintC argcount,
uintL* index_) {
(gdb) p fun
$3 = (object) 0x10150eb5
(gdb) bt
#0 0x0042b512 in subscripts_to_index (array=0x10150eb5,
argptr=0x0,
argcount=2, index_=0x33020) at array.d:483
#1 0x0042b72d in C_aref (argcount=2,
rest_args_pointer=0x107ea44)
at array.d:714
#2 0x00438e03 in apply_subr (fun=0x4e0832,
args_on_stack=17295940,
args=0x102fdeb3) at eval.d:4465
#3 0x0043a19c in interpret_bytecode_ (closure=0x10233fcd,
codeptr=0x10233fa0,
byteptr_in=0x10233fb2
"Uk\001 w\001Ü3\001-\037\t\016\003xr2\004Y\031\002\031
\002") at eval.d:7112
#4 0x0043b066 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:7069
#5 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#6 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#7 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#8 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#9 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
---Type <return> to continue, or q <return> to quit---q
codeptr=0x10233f2c, Quit
) at eval.d:6848
#10 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#11 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#12 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#13 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#14 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#15 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#16 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#17 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#18 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
#19 0x0043b413 in interpret_bytecode_ (closure=0x10233f89,
codeptr=0x10233f2c, byteptr_in=0x10233f3e "-k") at
eval.d:6848
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) xout fun
Program received signal SIGSEGV, Segmentation fault.
0x7c90377a in ntdll!RtlCopyOutOfProcessMemoryStreamTo ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
The program being debugged was signaled while in a function
called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function
(nobject_out) will be aband
oned.
(gdb)
Logged In: YES
user_id=1630354
PS: I've looked into the (possibly) related issue too. It's
a similar looking sort of thing:
https://sourceforge.net/tracker/index.php?func=detail&aid=1538436&group_id=1355&atid=101355
Logged In: YES
user_id=13755
Originator: NO
This was fixed in 2.40. Please use a recent package.
Logged In: YES
user_id=5735
Originator: NO
This bug report is now marked as "pending"/"works for me".
This means that we think that we cannot reproduce the problem
and cannot do anything about it.
Unless you - the reporter - act within 2 weeks
(e.g., by submitting a self-contained test case),
the bug will be permanently closed.
Sorry about the inconvenience -
we hope your silence means that
you are no longer observing the problem either.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).