Subject: [clisp-list] aborting MAKE-ARRAY leaves CLISP in an unstable state?

From: Carl Shapiro <[email-masked]>
Date: Sun Mar 3 15:24:02 2002

I am having some stability problems with CLISP.  Specifically,
aborting MAKE-ARRAY seems to leave CLISP in an unstable state.  Has
anyone else encountered similar problems when aborting MAKE-ARRAY?

I have included below a simple, reproducible example of the lossage I
am experiencing.

zzz$ uname -a
NetBSD zzz 1.5.2 NetBSD 1.5.2 (BRAIN) #1: Sat Sep 29 12:44:54
EDT 2001     root@zzz:/u1/src/sys/arch/i386/compile/BRAIN i386
zzz$ clisp --version

[1]> GNU CLISP 2.27 (released 2001-07-17) (built on zzz)
zzz$ clisp -q -I

[1]> (make-array 10000000)
^C
** - Continuable Error
PRINT: User break
If you continue (by typing 'continue'): Continue execution
1. Break [2]> :bt

- NIL
1. Break [2]> :a

[3]> (ext:gc)
3672424
[4]> (ext:gc)
Segmentation fault
zzz$

---

From: Sam Steingold <[email-masked]>
Date: Sun Mar 3 19:31:07 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] aborting MAKE-ARRAY leaves CLISP in an unstable state?"
> * Sent on Sun, 3 Mar 2002 18:22:59 -0500 (EST)
> * Honorable Carl Shapiro <[email-masked]> writes:
>

this is in PRINT, not MAKE-ARRAY
please try
(make-list 10000000)
^C
do you get the same?
could you play with the various *PRINT-* vars to determine what makes
this happen?

> If you continue (by typing 'continue'): Continue execution

wow!!! in the _second_ GC!

do you get a core?
can you generate a backtrace?
(you might need to rebuild with -g...)

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/>
Despite the raising cost of living, it remains quite popular.

---

From: Carl Shapiro <[email-masked]>
Date: Sun Mar 3 20:33:03 2002

From: Sam Steingold <[email-masked]>
   Date: 03 Mar 2002 22:25:39 -0500

If I break in the printer with *PRINT-LENGTH* set to NIL I can
reliably cause a segmentation fault on the first try.  With either
*PRINT-LENGTH* set to some small value or with printing of arrays
completely turned off I can reproduce the segfault.  However, this only
works if I have created some garbage before hand, say by making an
uninterrupted call to (MAKE-ARRAY 10000000).

bash-2.05$ clisp -q -I

[1]> (setq *print-array* nil)
NIL
[2]> (make-array 10000000)
#<ARRAY T (10000000)>
[3]> (make-array 10000000)
^C

** - Continuable Error
GC: User break
1. Break [4]> :a

[5]> (ext:gc)
3672448
[6]> (ext:gc)
Segmentation fault (core dumped)
bash-2.05$

Pretty weird, right?
 
Sometime today I realized that I had never manually invoked the CLISP
collector and so I gave it a try, and then did it a second time hoping
to get a hint as to what the return value signifies.  That's when I
first noticed the segmentation fault!    

   do you get a core?

I can get a core file, but my clisp isn't compiled with symbols so gdb
isn't very revealing.  I'll try recompiling with symbols tomorrow and
giving this another try.

hippocampus$ gdb --quiet
(gdb) file /usr/local/lib/clisp/base/lisp.run
Reading symbols from /usr/local/lib/clisp/base/lisp.run...
(no debugging symbols found)...done.
(gdb) core lisp.run.core
Core was generated by `lisp.run'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.elf_so...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libtermcap.so.0...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libc.so.12...(no debugging symbols found)...done.
#0  0x804b58a in gc_morris2 ()
(gdb) where
#0  0x804b58a in gc_morris2 ()
#1  0x2297cbbc in ?? ()
Cannot access memory at address 0x680a7000.
(gdb) info local
No symbol table info available.
(gdb)

---

From: Sam Steingold <[email-masked]>
Date: Mon Mar 4 06:30:14 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] aborting MAKE-ARRAY leaves CLISP in an unstable state?"
> * Sent on Sun, 3 Mar 2002 23:32:50 -0500 (EST)
and?

> reliably cause a segmentation fault on the first try.

I was also interested in *print-pretty*.

So, what is the combination of vars that gets the crash the earliest?

> to get a hint as to what the return value signifies.

impnotes.html is your friend...

> isn't very revealing.  I'll try recompiling with symbols tomorrow and

I do not observe this in the current CVS, and my hardware is totally
inadequate for intensive configure/build/test cycles, so I would
appreciate it if you could try to use binary search to find out _when_
the bug was introduced.
use CVS - get the earliest revision, check whether the crash is there,
if not - try a revision midway between then and now...

good luck...

-- 
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/>
Please wait, MS Windows are preparing the blue screen of death.