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

[Faré]

a big TERMCAP and an ARGV0 of length <= 7 reveals the bug.
It looks like the overall size and/or alignment of the environment in
general may contribute to revealing the bug or not.

Indeed, trying to reproduce the bug with a different environment
causes a very different pattern in when the bug is triggered.
Sometimes, I don't even need to change TERM or TERMCAP.

If you can suggest other things to try, I'll be glad.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Every program has at least one bug and can be shortened by at least one
instruction -- from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.


On 19/06/07, Faré <fahree at gmail.com> wrote:
> 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