Subject: [clisp-list] Compilation Failure: Latest Release (2.28) : RedHat 7.2 (Kernel 2.4.9-21)

From: IPmonger <[email-masked]>
Date: Tue Mar 5 01:33:02 2002

Folks,

    I just did a CVS update to the latest release (2.28) on my RedHat
  7.2 machine (running Kernel 2.4.9-21):

%  cvs -z3 -d:pserver:[email-masked]:/cvsroot/clisp co -r clisp_2_28-2002-03-03 clisp

and used the following configuration steps:

% cd clisp

% ./configure --with-readline --with-nogettext --with-dynamic-ffi \
  --with-dynamic-modules --with-export-syscalls --with-module=wildcard \
  --with-module=regexp --with-module=bindings/linuxlibc6 \
  --with-module=clx/new-clx --build build

lisp.run builds ok, then loads all the modules to dump interpreted.mem:
 ./lisp.run -B . -Efile UTF-8 -norc -m 750KW \
     -x "(load \"init.lisp\") (sys::%saveinitmem) (exit)"

next, using the interpreted.mem image, we compile "compiler.lisp":
./lisp.run -B . -Efile UTF-8 -norc -m 1000KW -M interpreted.mem -q -c compiler.lisp

  which works fine, so we try to load the images with only 750KW and no
  specified image:

./lisp.run -B . -Efile UTF-8 -norc -m 750KW \
   -x "(load \"init.lisp\") (sys::%saveinitmem) (exit)"

  but this bombs with a segfault:

;; Loading file /usr/local/src/clisp/build/deprecated.lisp ...
;; Loading of file /usr/local/src/clisp/build/deprecated.lisp is finished.
*** - handle_fault error2 ! address = 0x203C5000 not in [0x202BD000,0x203866E4) !
SIGSEGV cannot be cured. Fault address = 0x203C5000.
make: *** [halfcompiled.mem] Segmentation fault

  Can someone suggest something to try?

-IPmonger
-- 
------------------
IPmonger
[email-masked]
CCIE #8338

---

From: Sam Steingold <[email-masked]>
Date: Tue Mar 5 16:58:04 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Compilation Failure: Latest Release (2.28) : RedHat 7.2 (Kernel 2.4.9-21)"
> * Sent on Tue, 05 Mar 2002 04:32:52 -0500
> * Honorable IPmonger <[email-masked]> writes:
>
> 

edit Makefile, remove optimizations and replace -O2 with -g, then get
the backtrace.

thanks.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Booze is the answer. I can't remember the question.

---

From: IPmonger <[email-masked]>
Date: Tue Mar 5 23:12:03 2002

Sam,

> edit Makefile, remove optimizations and replace -O2 with -g, then get

    I configured in directory "with-gcc-wall" and then edited the
  Makefile to remove the -O2 and added -g3.  I manually went through the
  steps and they all passed w/out a problem, including "make test" and
  "make testsuite".

    So, I configured in directory "with-gcc-wall-o2" and left the
  optimizations turned on (-O2) but added debugging (-g3).  The point a
  which it fails varies from scenario to scenario.  What doesn't vary is
  that it fails while trying to load a compiled .fas file.  What does
  vary is which file:  under gdb it fails *sooner* than when run w/out
  gdb.  Here's what gdb has to say:

  ;; Loading file format.fas ...
  Program received signal SIGSEGV, Segmentation fault.
  0x080a2ec6 in read_delimited_list_recursive 
   (stream_=Cannot access memory at address 0x14c7) at io.d:2548

  2548          Cdr(STACK_0) = new_cons; # =: (cdr (last Gesamtliste))

    The failure under gdb is always this same line.

    It seems like there might be a problem with optimization...

-jon
-- 
------------------
Jon Allen Boone
[email-masked]
CCIE #8338

---

From: Sam Steingold <[email-masked]>
Date: Wed Mar 6 11:34:30 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] Compilation Failure: Latest Release (2.28) : RedHat 7.2 (Kernel 2.4.9-21)"
> * Sent on Wed, 06 Mar 2002 02:11:13 -0500

add -DDEBUG_EVAL -DDEBUG_SPVW to CFLAGS.

I use the exact same distribution and kernel here and I do not observe
this.
is it possible that you have some weird configuration issue (like some
libraries were compiled with gcc3 and other with gcc 2.96)?

is the crash totally predictable (I mean the place & time, not CRASH-P)?
if yes and you can stop in gdb right before the crash reliably, try
(gdb) p gar_col()
after pushSTACK(object1);  but before allocate_cons(); and see is the
crash goes away or happens inside GC.
also, do
(gdb) p object_out(object1)
and
(gdb) p STACK_0 (and STACK_1)...

the last resort would be for me to telnet to your machine and debug it
remotely... (I would hate to have to do this)

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Lisp: it's here to save your butt.

---

From: IPmonger <[email-masked]>
Date: Thu Mar 7 23:45:06 2002

> add -DDEBUG_EVAL -DDEBUG_SPVW to CFLAGS.

    Ok, so I did this and it fails to compile spvw.c because of problems
  in spvw_general.d:

spvw_genera1.d:948: structure has no member named `heapnr_from_type'
spvw_genera1.d:953: structure has no member named `heapnr_from_type'
spvw_genera1.d:962: `symbol_type' undeclared (first use in this function)

    These are caused by the -DDEBUG_SPVW flag.

    the heapnr_from_type member of the mem struct is only present if the
  following are true (spvw_global.d, lines 44-54):

        #if defined(SPVW_MIXED_BLOCKS) && defined(TYPECODES) && defined(GENERATIONAL_GC)
          sintB heapnr_from_type[typecount]; # Tabelle type -> heapnr
        #endif

        #if defined(SPVW_MIXED_BLOCKS_OPPOSITE) && !defined(TRIVIALMAP_MEMORY)
          # now empty, free for Lisp objects.
          #define MEMRES  conses.heap_end
          # now the emergency reserve
          # Upper limit of big allocated memory block.
          aint MEMTOP;
        #endif

  GENERATIONAL_GC, SPVW_MIXED_BLOCKS, SPVW_MIXED_BLOCKS_OPPOSITE and
  TRIVIALMAP_MEMORY are all defined, but TYPECODES are not -
  NO_TYPECODES are instead.  So, there is a bug here in spvw_genera1.d,
  lines 945-957, as not all SPVW_MIXED are the same.

        #ifdef SPVW_PURE
        heap = &mem.heaps[type];
        #else # SPVW_MIXED
        heap = &mem.heaps[mem.heapnr_from_type[type]];
        #endif
        if ((addr >= heap->heap_gen0_start) && (addr < heap->heap_gen0_end))
          return false;
        #ifdef SPVW_MIXED_BLOCKS_OPPOSITE
        if (is_cons_heap(mem.heapnr_from_type[type])) {
          if ((addr >= heap->heap_start) && (addr < heap->heap_gen1_end))
            return true; # Pointer in die neue Generation
        } else
        #endif

    I don't know enough about what's going on to even offer a suggestion
  as to how to fix it, though.  :-(

    The error about symbol_type is due to the fact that TYPECODES is not
  defined. 

>    I use the exact same distribution and kernel here and I do not
>  observe this.  is it possible that you have some weird configuration
>  issue (like some libraries were compiled with gcc3 and other with gcc
>  2.96)?

    I don't think so because I personally never use gcc3.  However, I
  have run the RedHat up2date facility and *they* might have done that. 

>    is the crash totally predictable (I mean the place & time, not

    yes.

>  (gdb) p STACK_0 (and STACK_1)...

    I'll try these as well, once I get it to compile with the debugging
  statements you've suggested above that seem to be causing problems.

-IPmonger
-- 
------------------
IPmonger
[email-masked]
CCIE #8338

---

From: Sam Steingold <[email-masked]>
Date: Fri Mar 8 08:28:06 2002

> * In message <[email-masked]>
> * Sent on Fri, 08 Mar 2002 02:44:41 -0500

I guess not all options work together.
add -DSAFETY=3.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
char*a="char*a=%c%s%c;main(){printf(a,34,a,34);}";main(){printf(a,34,a,34);}

---

From: IPmonger <[email-masked]>
Date: Fri Mar 8 18:45:06 2002

Sam,

    Let me start by thanking you for your help.  I appreciate you giving
  so much time to me.  I'm sorry that I can't be more productive in
  providing debugging information.

> I guess not all options work together.

    I did this.  It now compiles.

    It still crashes during the half-compiled stage, but after loading a
  different file.  :-)

    I'll follow the recommendations you had previously given me and see
  if I can produce anything useful.  Thanks again for your help.

-IPmonger
-- 
------------------
IPmonger
[email-masked]
CCIE #8338