Re: [clisp-list] What causes hard exits from clisp?

[Christophe R. <cs...@ca...>]

On Wed, Apr 24, 2002 at 09:23:16AM -0400, Sam Steingold wrote:
> > * In message <200...@ca...>
> > * On the subject of "Re: [clisp-list] What causes hard exits from clisp?"
> > * Sent on Wed, 24 Apr 2002 09:13:26 +0100
> > * Honorable Christophe Rhodes <cs...@ca...> writes:
> >
> > I've attached a slightly fuller backtrace from the CVS version of
> > CLISP, compiled with ./configure --with-debug, on the same
> > application. It crashes in the same place, from a user point of view,
> > though the small-numbered stack frames in this backtrace are slightly
> > different in the detail.
> > 
> > fehler_funname_source appears at frames 45, 80, and 115 of the
> > attached (hmm, 35 frames..., yes, also 150 and 185)
> 
> fine.  please stop in an inner fehler_funname_source() and print all
> arguments in all the 35 (hmm - please make it 70 - I want to know the
> how the two adjacent periods differ) frames separating this
> fehler_funname_source() and the one above (print objects with zout).

Right. I've tried to look at this problem (not just the weird
fehler_funname_source thing, the whole sbcl-compile-under-clisp and
garbage-collection problem).

Firstly, let me say that the symptom discussed above seems to be an
artifact of having corrupted data; I _think_ what is going on is that
fehler_funname_source is trying to print

  *** - EVAL: <something> is not a function name

and failing because the <something> is a corrupt object; this then lands
it into confused recursive error territory. I could be wrong, of course,
but

  (gdb) frame 0
  #0  fehler_funname_source (caller=0x8247665, obj=0x8246379) at error.d:914
  914	  pushSTACK(obj); pushSTACK(caller);
  (gdb) zout caller
  ; EVAL
  $2 = (void *) 0x8247665

leads me to that diagnosis. (zouting obj, and most other things in the
backtrace at this point, reliably cause segfaults).

As for

  *** - handle_fault error2 ! address = 0xC0 not in [0x202AF000,0x20A2511C) !
  SIGSEGV cannot be cured. Fault address = 0xC0.
  Segmentation fault

well, I have tried wandering about the stack, stopping before this
segfault, but I confess that I haven't managed to find anything out.

However, sbcl's CVS is now in a state where it makes sense to give
instructions for replicating this failure, in case anyone else would
like to try their hand... it's still a little involved, so bear with me.

Firstly, to check out sbcl from CVS, do

  cvs -d:pserver:ano...@cv...:/cvsroot/sbcl co sbcl

(with optional -z3 for compression, and possibly having done cvs login
first). To this, you will need to apply the attached patch (which
represent things that are needed to make some internals work under
clisp, but aren't understood sufficiently well to be committed to CVS),
with, from within the sbcl directory:

  patch -p0 < clisp-build.diff

[ feel free to look at it and explain the twisted reasoning behind the
  cmucl-derived code :-) ]

Then (and this bit assumes that you're running on x86/linux; if you're
not, this procedure is still possible, though more complex, so let me
know if you'd like the instructions):

user@host:path/to/sbcl$ sh ./make-config.sh
[ ... sets up relevant symlinks ... ]
user@host:path/to/sbcl$ SBCL_XC_HOST='path/to/clisp' sh ./make-host-1.sh
[ ... builds a cross-compiler, and dumps a header file needed to build
  the runtime ... this bit should go without errors ]
user@host:path/to/sbcl$ GNUMAKE=make sh ./make-target-1.sh
[ ... builds the runtime ... this bit should go with plenty of warnings
  but without errors ]
user@host:path/to/sbcl$ path/to/clisp
and then you get a clisp prompt
[1]> 
at which point you start pasting in forms from make-host-2.sh; normally
this would be run uninteractively, but you're going to need
interaction... so starting with the 
  (setf *print-level* 5 *print-length* 5)
  (load "src/cold/shared.lisp")
  (in-package "SB-COLD")
  ...
carry on pasting in forms one by one. After pasting in
  (load-or-cload-xcompiler #'host-load-stem)
clisp should load the cross-compiler fas files;
then, once you get down to
  (load "src/cold/compile-cold-sbcl.lisp")
the cross-compiler should start running, printing plenty of diagnostic
messages as is a verbose compiler's wont.

During compilation of src/code/pred.lisp, a continuable error is
signalled (for some reason that I haven't yet tracked down, SBCL wants
to intern "NIL-1" into the CL package; this is a bug in SBCL, but it can
be "continue"d from for now; then, about a minute later, during
compilation of src/code/array.lisp, I get this segfault the cause of
which I have not had very much success in finding :-(

I appreciate that this is the kind of bug report that is a nightmare
(it's not exactly a "small reproduceable test case", is it?), so I
understand if no-one gets round to tracking it down for a while... but
if anyone does have the time even to verify this, it would probably
help.

Many thanks,

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)