I cannot reproduce at this time.
When I tried to reproduce earlier, the bug was very sensitive to some
unidentified parameters. While in a given shell, changing the TERMCAP
variable as shown would trigger the bug, in another shell it wouldn't.
It could be some buffer overflow of some sort, or anyt
Hi Faré!
On Wed, 20 Jun 2007 05:03:41 +0200, Faré wrote:
> a big TERMCAP and an ARGV0 of length <= 7 reveals the bug.
I cannot reproduce it on etch nor on a clean sid chroot:
=
$ export TERM=screen.linux
$ export TERMCAP='SC|screen.linux|VT 100/ANSI X3.64 virtual terminal:\
:hs:ts=\E_
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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...
What does strace say?
Groetjes, Peter
- --
sig
It's pretty reproducible here, with cmucl 19d-20061116-1, which is the
latest I find in unstable. When you test it, does your $TERM match
your $TERMCAP ? Otherwise, cmucl might not be trying to use it.
TERM=screen.linux
TERMCAP='SC|screen.linux|VT 100/ANSI X3.64 virtual terminal:\
:hs:ts=\
Faré wrote:
After some experimentation, it looks like the problem is a buffer
overflow (of all things!) when variable $TERMCAP is too big.
Interesting. And dangerous.
But I cannot reproduce it:
$ echo $TERMCAP | wc -c
11448
$ cmucl
CMU Common Lisp CVS 19d 19d-release (19D), running on frost
W
After some experimentation, it looks like the problem is a buffer
overflow (of all things!) when variable $TERMCAP is too big.
Removing an entry from $TERMCAP makes cmucl happy. Making one
lengthier again makes it unhappy again.
PS: cl-launch
[ François-René ÐVB Rideau | Reflection&Cybernethics
Using a custom-compiled kernel 2.6.18 (has to be custom - or it won't
boot on this crypto'ed machine), I have exactly the same symptoms
(plus other unrelated trouble trying to resume-from-ram). I don't
think it is kernel-related.
Actually, I realize that it dies when I'm within screen with
TERM=s
On Saturday 20 January 2007 05:28, Faré wrote:
> *** Please type your report below this line ***
> Since I last upgraded cmucl, I get the following error and backtrace
> whenever I start it.
>
> $ cmucl
>
>
> Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at
#x10044FB8.
>[
Package: cmucl
Version: 19d-20061116-1
Severity: normal
*** Please type your report below this line ***
Since I last upgraded cmucl, I get the following error and backtrace
whenever I start it.
$ cmucl
Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x10044FB8.
[Condition
11 matches
Mail list logo
