From: SourceForge.net <no...@so...> - 2006-03-20 16:28:10
|
Bugs item #1411868, was opened at 2006-01-22 05:22 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1411868&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: segfault Status: Open Resolution: None Priority: 5 Submitted By: Sam Steingold (sds) Assigned to: Bruno Haible (haible) Summary: win32 Crash on infinite recursion / program stack overflow Initial Comment: [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) ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-03-20 17:28 Message: 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 ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-06 10:01 Message: 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. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2006-03-01 16:16 Message: 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) ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-01 16:04 Message: 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. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-02-07 18:55 Message: 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) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1411868&group_id=1355 |