From owner-freebsd-bugs Mon Jul 22 14:43:49 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13085 for bugs-outgoing; Mon, 22 Jul 1996 14:43:49 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA13059 for ; Mon, 22 Jul 1996 14:43:42 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA19913; Mon, 22 Jul 1996 23:43:25 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA05935; Mon, 22 Jul 1996 23:43:23 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id XAA07235; Mon, 22 Jul 1996 23:37:05 +0200 (MET DST) From: J Wunsch Message-Id: <199607222137.XAA07235@uriah.heep.sax.de> Subject: Re: bin/1411: vi dumps core when using 'set list' To: marcs@valis.worldgate.com Date: Mon, 22 Jul 1996 23:37:05 +0200 (MET DST) Cc: freebsd-bugs@FreeBSD.org (FreeBSD bugs list), bostic@bostic.com (Keith Bostic) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from j at "Jul 22, 96 10:46:53 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk 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 : cmpl $0xfe,0xffffffd8(%ebp) 0x2c0f2 : jg 0x2c110 Here's the comparision against MAX_FAST_KEY (254 alias 0xfe). 0x2c0f4 : movl 0x8(%ebp),%edi 0x2c0f7 : movl 0x8(%edi),%eax Now, %eax contains sp->gp. 0x2c0fa : movl 0xffffffd8(%ebp),%ecx 0x2c0fd : leal (%ecx,%ecx,2),%edx That's `ch' taken, and shifted left by four, to form sp->gp->cname[ch]. 0x2c100 : movb 0x91(%eax,%edx,2),%al That's finally the failing instruction, where the bad memory access happens. Now: (gdb) x 0xffffffd8 + $ebp 0xefbfd0e0 : 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. ;-)