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
5 matches
Mail list logo
