#374 Program stack overflow. RESET -> Internal error

lisp error
closed-works-for-me
clisp (525)
5
2014-08-15
2006-10-26
szergling
No

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.

Discussion

  • szergling

    szergling - 2006-10-26

    Problem isolated into this file.

     
  • szergling

    szergling - 2006-11-06

    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)

     
  • Reini Urban

    Reini Urban - 2007-01-22

    Logged In: YES
    user_id=13755
    Originator: NO

    This was fixed in 2.40. Please use a recent package.

     
  • Sam Steingold

    Sam Steingold - 2008-01-24
    • assigned_to: haible --> sds
    • status: open --> pending-works-for-me
     
  • Sam Steingold

    Sam Steingold - 2008-01-24

    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.

     
  • SourceForge Robot

    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).

     
  • SourceForge Robot

    • status: pending-works-for-me --> closed-works-for-me
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks