Bug#407606: [cl-debian] Bug#407606: cmucl fails at initialization

[Faré]

OK, it gets weirder.

On the zsh command-line, I can make it fail deterministically. In a sh
script, it deterministically works. I traced that to the argv[0].
Using zsh, I can explicitly call
#!/bin/zsh -f
ARGV0=cmucl /usr/bin/cmucl
and have it fail deterministically (given the appropriately long
TERMCAP and TERM -- otherwise it still works).

Note that in the backtrace, those frames are fishy:
10: (KERNEL:CSUBTYPEP #<ARRAY-TYPE SIMPLE-BASE-STRING> #<UNION-TYPE LIST>)
11: (MAKE-SEQUENCE SIMPLE-STRING 15 :INITIAL-ELEMENT NIL)
12: (LISP::CONCAT-TO-SIMPLE* SIMPLE-STRING "/home/fare/bug" "/")

The initial-element NIL is "undefined behaviour" when a BASE-CHAR is
otherwise wanted. This is in CONCAT-TO-SIMPLE* from code/seq.lisp. The
compiler might be confused between inferred types and producing
something fishy.

When I start cmucl and get it in buggy mode, then trying to
(LISP::CONCAT-TO-SIMPLE* 'SIMPLE-STRING "/home/fare/bug" "/")
or
(MAKE-SEQUENCE 'SIMPLE-STRING 15 :INITIAL-ELEMENT NIL)
from the debugger's REPL consistently cause the same SIGSEGV. Whereas
when I start it in non-buggy mode, the former gives the expected
result "/home/fare/bug/" (the current directory) and the latter
correctly gives a Type-error in
KERNEL::OBJECT-NOT-BASE-CHAR-ERROR-HANDLER:
   NIL is not of type BASE-CHAR
This suggests an issue with low-safety evaluation. How do I check the
"current" safety settings?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The program isn't debugged until the last user is dead.

On 08/05/07, Faré <fahree at gmail.com> wrote:
> On 04/05/07, Peter Van Eynde <pvaneynd at debian.org> wrote:
> > Hello Faré
> >
> > I tried with the environment set as you gave, but still it works.
> > Actually I cannot find serious references to TERMCAP in the cmucl
> > sources so I fail to see where it could crash the image...
> There is a hemlock/termcap.lisp and a hemlock/rompsite.lisp, where the
> environment variable is used. Maybe it would help if these were
> compiled with a better debugging setting?
>
> > What does strace say?
> strace and ltrace output attached.
> Not very informative to me.
>
> NB: regarding the suggestion by Pierre Thierry, I wouldn't know what to ask GDB.
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> The main difference between a computer salesman and a used car salesman is
> that the used car salesman can probably drive and knows when he's lying.
>         - Peter da Silva