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é <[EMAIL PROTECTED]> 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é <[EMAIL PROTECTED]> wrote: > On 04/05/07, Peter Van Eynde <[EMAIL PROTECTED]> 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
