#312 win32 Crash on infinite recursion / program stack overflow

segfault
closed-fixed
clisp (524)
5
2006-05-05
2006-01-22
No

[1]> (defun f () (f))
F
[2]> (f)

*** - Program stack overflow. RESET

*** - handle_fault error2 ! address = 0xfffffffc not in
[0x5ffa2f78,0x60000000)
!
SIGSEGV cannot be cured. Fault address = 0xfffffffc.
Permanently allocated: 87776 bytes.
Currently in use: 1637280 bytes.
Free space: 517308 bytes.

this appears to be gengc-specific.

running under GDB results in a segfault:
Starting program:
/cygdrive/d/gnu/clisp/current/build-O-mingw/lisp.exe -B
. -N l
ocale -E 1:1 -q -norc -M lispinit.mem

Program received signal SIGSEGV, Segmentation fault.
0x00453ab4 in closed_buffered (stream=0x1a21ff2d) at
stream.d:7982
7982 BufferedStream_channel(stream) = NIL; #
Handle becomes invalid
(gdb) where
#0 0x00453ab4 in closed_buffered (stream=0x1a21ff2d)
at stream.d:7982
#1 0x0045c51d in closed_all_files () at stream.d:15893
#2 0x00417454 in loadmem_from_handle (handle=0x350,
filename=0x835c31 "lispinit.mem") at
spvw_memfile.d:1621
#3 0x00416180 in loadmem (filename=0x835c31
"lispinit.mem")
at spvw_memfile.d:922
#4 0x004138e0 in init_memory (p=0x5ad5d8) at spvw.d:2901
#5 0x00412738 in main (argc=11, argv=0x835e60) at
spvw.d:3231
(gdb) list
7977 # UP: Declares a File-Stream as closed.
7978 # closed_buffered(stream);
7979 # > stream : (open) File-Stream.
7980 # changed in stream: all Components except name
and truename
7981 local void closed_buffered (object stream) {
7982 BufferedStream_channel(stream) = NIL; #
Handle becomes invalid
7983 BufferedStream_buffer(stream) = NIL; # free
Buffer
7984 BufferedStream_buffstart(stream) = 0; #
delete buffstart (unnecessary)

7985 BufferedStream_endvalid(stream) = 0; # delete
endvalid (unnecessary)
7986 BufferedStream_index(stream) = 0; # delete
index (unnecessary)
(gdb) xout stream
#<built-in-stream type=12 flags=129 len=22 xlen=64
slen=14 file name=#(CL::PATHN
AME :HOST CL::NIL :DEVICE CL::NIL :DIRECTORY CL::NIL
:NAME "lispinit" :TYPE "mem
" :VERSION :NEWEST) truename=#(CL::PATHNAME :HOST
CL::NIL :DEVICE "D" :DIRECTORY
(:ABSOLUTE "gnu" "clisp" "current" "build-O-mingw")
:NAME "lispinit" :TYPE "mem
" :VERSION :NEWEST) channel=808 eltype=CL::CHARACTER
encoding=#<encoding eol=:DO
S wce=:ERROR mbe=:ERROR cs=CHARSET::UTF-8 0x1a0ffb21>
0x1a21ff2d>(void *) 0x1a21
ff2d
(gdb)

Discussion

  • Jörg Höhle

    Jörg Höhle - 2006-02-07

    Logged In: YES
    user_id=377168

    Possibly same as bug #1180386
    Linux/x686 crashes as well with even less messages
    [1]> (defun f () (f))
    F
    [2]> (f)
    Speicherzugriffsfehler
    (both clisp-2.35 from Debian Ubuntu Breezy and CLISP/CVS
    from ~January 2006)

     
  • Jörg Höhle

    Jörg Höhle - 2006-03-01

    Logged In: YES
    user_id=377168

    Did you test with mingw or cygwin?
    Does the mingw build use an native MS-Windows
    libcallback.lib or does it provide generational GC via a
    UNIX emulation layer (mprotect etc.)?
    Since the MS-VC6 build does not crash but my Linux build
    does, maybe MINGW crash or not crashing behaviour could help
    restrict the bug location.
    Note also that my Linux builds only crash when
    GENERATIONAL_GC is there. build-debug or -DSAFETY=3
    disables gen.gc and clisp does not dump core then.

     
  • Sam Steingold

    Sam Steingold - 2006-03-01

    Logged In: YES
    user_id=5735

    this is mingw (with libsigsegv).
    IIUC, no unix stuff is used.
    note that I no longer have any access to windows.
    I used to build using
    ./configure --with-mingw --build build-O-mingw
    on cygwin. you can easily reproduce this
    (installing cygwin is very easy)

     
  • Jörg Höhle

    Jörg Höhle - 2006-03-06

    Logged In: YES
    user_id=377168

    >this appears to be gengc-specific.
    >Program received signal SIGSEGV, Segmentation fault.
    > 0x00453ab4 in closed_buffered (stream=0x1a21ff2d) at
    > stream.d:7982
    This is what I obtain when I forget
    handle SIGSEGV noprint nostop
    handle SIGBUS noprint nostop
    (see .gdbinit). It has nothing to do with the bug.

     
  • Jörg Höhle

    Jörg Höhle - 2006-03-20

    Logged In: YES
    user_id=377168

    I wrote:
    >Note also that my Linux builds only crash when
    >GENERATIONAL_GC is there. build-debug or -DSAFETY=3
    >disables gen.gc and clisp does not dump core then.
    This is an artefact of the default for the -m option (either
    2 or 14MB). It has nothing to do with gen.gc.
    -m14MB will lead to a crash (given ulimit -s 8192KB)
    regardless of SAFETY, NO_GENERATIONAL_GC or
    CONS_STACK_GROWS_UP.
    -m2MB will catch a Lisp stack (STACK) overflow, before clisp
    gets an opportunity to die from a program stack (SP)
    overflow.

    Since you don't have the machine which shows the bug
    anymore, you sadly can't go near the crash place (e.g. abort
    after 3758 recursions), call SP_ueber() or
    near_SP_overflow() and see if that causes different results

     
  • Jörg Höhle

    Jörg Höhle - 2006-04-18
    • assigned_to: haible --> hoehle
     
  • Jörg Höhle

    Jörg Höhle - 2006-05-05
    • status: open --> closed-fixed
     
  • Jörg Höhle

    Jörg Höhle - 2006-05-05

    Logged In: YES
    user_id=377168

    thank you for your bug report.
    the bug has been fixed in the CVS tree.
    you can either wait for the next release (recommended)
    or check out the current CVS tree (see http://clisp.cons.org\)
    and build CLISP from the sources (be advised that between
    releases the CVS tree is very unstable and may not even build
    on your platform).

     

Log in to post a comment.