Date: Mon, 22 Jul 1996 23:37:05 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: marcs@valis.worldgate.com Cc: freebsd-bugs@FreeBSD.org (FreeBSD bugs list), bostic@bostic.com (Keith Bostic) Subject: Re: bin/1411: vi dumps core when using 'set list' Message-ID: <199607222137.XAA07235@uriah.heep.sax.de> In-Reply-To: <no.id> from j at "Jul 22, 96 10:46:53 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As j wrote:
> > Hmm. Well, I tried compiling it once again, this time with CFLAGS set to
> > "-O2 -m486 -pipe" and the problem was not there. Trying with "-O2 -m486",
> > the problem still wasn't there. With one of -O2 or -m486, it is still
> > there. Hey, I just tried -m486 again and it won't show up. Grr. Try
> > just using -O2 and see if you can make it show up.
>
> Ah, that's the key. Now i'm getting it, too!
Well, i can now see the error. It still occurs when compiling with
-g, and happens inside function svi_line() here:
if (scno < cols_per_screen) {
/* If didn't paint the whole line, update the cache. */
smp->c_ecsize = smp->c_eclen = KEY_LEN(sp, ch);
^^^^^^^^^^^^^^^
smp->c_eboff = len - 1;
KEY_LEN itself is a macro:
#define KEY_LEN(sp, ch) \
((ch) <= MAX_FAST_KEY ? \
sp->gp->cname[ch].len : __key_len(sp, ch))
The bug experiences since `ch' in the given context is declared as a
(signed) int, but apparently contains a stack address. That's the
failing piece of code:
0x2c0eb <svi_line+1695>: cmpl $0xfe,0xffffffd8(%ebp)
0x2c0f2 <svi_line+1702>: jg 0x2c110 <svi_line+1732>
Here's the comparision against MAX_FAST_KEY (254 alias 0xfe).
0x2c0f4 <svi_line+1704>: movl 0x8(%ebp),%edi
0x2c0f7 <svi_line+1707>: movl 0x8(%edi),%eax
Now, %eax contains sp->gp.
0x2c0fa <svi_line+1710>: movl 0xffffffd8(%ebp),%ecx
0x2c0fd <svi_line+1713>: leal (%ecx,%ecx,2),%edx
That's `ch' taken, and shifted left by four, to form sp->gp->cname[ch].
0x2c100 <svi_line+1716>: movb 0x91(%eax,%edx,2),%al
That's finally the failing instruction, where the bad memory access
happens.
Now:
(gdb) x 0xffffffd8 + $ebp
0xefbfd0e0 <end+3887255480>: 0xefbfd100
That's the current value of `ch'. Since it is being cast to an int,
it is negative, and thus unintentionally less than 254, but of course
still way out of bounds for the cname[] array. I'm not quite familar
with that code, but it simply looks as if `ch' were uninitialized in
that particular case. This would explain why it only happens with
-O2, but not with -O2 -m486.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607222137.XAA07235>