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@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@gmail.com> wrote:
On 04/05/07, Peter Van Eynde <pvaneynd@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