From marcs@worldgate.com  Sat Jul 20 16:17:07 1996
Received: from valis.worldgate.com (root@valis.worldgate.com [198.161.84.2])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA23623
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 20 Jul 1996 16:17:06 -0700 (PDT)
Received: from gras-varg.worldgate.com (root@gras-varg.worldgate.com [198.161.84.12]) by valis.worldgate.com (8.6.12/8.6.12) with ESMTP id RAA28793 for <FreeBSD-gnats-submit@freebsd.org>; Sat, 20 Jul 1996 17:17:05 -0600
Received: (from marcs@localhost) by gras-varg.worldgate.com (8.7.5/8.6.12) id RAA13314; Sat, 20 Jul 1996 17:17:04 -0600 (MDT)
Message-Id: <199607202317.RAA13314@gras-varg.worldgate.com>
Date: Sat, 20 Jul 1996 17:17:04 -0600 (MDT)
From: marcs@worldgate.com
Reply-To: marcs@worldgate.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: vi dumps core when using 'set list'
X-Send-Pr-Version: 3.2

>Number:         1411
>Category:       bin
>Synopsis:       vi dumps core when scrolling through files in 'set list' mode
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    peter
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul 20 16:20:01 PDT 1996
>Closed-Date:    Wed Sep 25 17:08:41 PDT 1996
>Last-Modified:  Wed Sep 25 17:09:52 PDT 1996
>Originator:     marcs@worldgate.com
>Release:        FreeBSD 2.1-STABLE i386
>Organization:
>Environment:

2.1.5-RELEASE; also stable for the week or two (at least) leading
up to release.


>Description:

After doing a ':set list', when a line is just long enough so that
the last character before the '$' indicating end of line would be
in column 80, vi core dumps when it gets to displaying the '$' on
the next line.

After recompiling vi with debugging information, gdb gives me the following:

$ gdb vi/common/nvi nvi.core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd),
Copyright 1994 Free Software Foundation, Inc...
Core was generated by `nvi'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x76010.
#0  0x312b6 in svi_line (sp=0x3f800, ep=0x45100, smp=0x869cc, yp=0x0, xp=0x0)
    at /usr/var/tmp/vi/common/../svi/svi_line.c:376
376                     smp->c_ecsize = smp->c_eclen = KEY_LEN(sp, ch);
(gdb) where
#0  0x312b6 in svi_line (sp=0x3f800, ep=0x45100, smp=0x869cc, yp=0x0, xp=0x0)
    at /usr/var/tmp/vi/common/../svi/svi_line.c:376
#1  0x3f800 in end ()
#2  0x34695 in svi_sm_1up (sp=0x3f800, ep=0x45100)
    at /usr/var/tmp/vi/common/../svi/svi_smap.c:766
#3  0x31a12 in svi_paint (sp=0x3f800, ep=0x45100)
    at /usr/var/tmp/vi/common/../svi/svi_refresh.c:314
#4  0x3162c in svi_refresh (sp=0x3f800, ep=0x45100)
    at /usr/var/tmp/vi/common/../svi/svi_refresh.c:140
#5  0x2e2e5 in vi (sp=0x3f800, ep=0x45100)
    at /usr/var/tmp/vi/common/../vi/vi.c:100
#6  0x32f24 in svi_screen_edit (sp=0x3f800, ep=0x45100)
    at /usr/var/tmp/vi/common/../svi/svi_screen.c:225
#7  0x580c in main (argc=2, argv=0xefbfdd60) at main.c:435

The binary I'm using and the core file it generated are available
upon request.  I'm not sure that this is a problem involving only
vi, since the vi source does not seem to have any significant
changes from 2.1.0 and the problem was not present in 2.1.0

>How-To-Repeat:

Using version 1.36.4.5 of sys/scsi/st.c, input the following from the keyboard:

	vi st.c
	:set list 
	172j12jj

After the last j, vi core dumps displaying line 185.  Same thing
happens when scrolling via other means, but not when you go to line
185 before doing a 'set list', and then do a 'set list'.


>Fix:
	
	

>Release-Note:
>Audit-Trail:

From: J Wunsch <j@uriah.heep.sax.de>
To: marcs@worldgate.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/1411: vi dumps core when using 'set list'
Date: Sun, 21 Jul 1996 09:47:16 +0200 (MET DST)

 As marcs@worldgate.com wrote:
 
 > >How-To-Repeat:
 > 
 > Using version 1.36.4.5 of sys/scsi/st.c, input the following from the keyboard:
 > 
 > 	vi st.c
 > 	:set list 
 > 	172j12jj
 > 
 > After the last j, vi core dumps displaying line 185.  Same thing
 > happens when scrolling via other means, but not when you go to line
 > 185 before doing a 'set list', and then do a 'set list'.
 
 It works for me, in a -current as of about one week old, and in an
 (24x80) xterm.
 
 Which vi version are you using, and which $TERM setting?
 
 -- 
 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. ;-)

From: Marc Slemko <marcs@valis.worldgate.com>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/1411: vi dumps core when using 'set list'
Date: Sun, 21 Jul 1996 14:24:27 -0600 (MDT)

 On Sun, 21 Jul 1996, J Wunsch wrote:
 
 > As marcs@worldgate.com wrote:
 > 
 > > >How-To-Repeat:
 > > 
 > > Using version 1.36.4.5 of sys/scsi/st.c, input the following from the keyboard:
 > > 
 > > 	vi st.c
 > > 	:set list 
 > > 	172j12jj
 > > 
 > > After the last j, vi core dumps displaying line 185.  Same thing
 > > happens when scrolling via other means, but not when you go to line
 > > 185 before doing a 'set list', and then do a 'set list'.
 > 
 > It works for me, in a -current as of about one week old, and in an
 > (24x80) xterm.
 
 I was doing the testing both from the sc console (with a $TERM of cons25),
 rlogin from various boxes ($TERM=vt100) and a remote xterm ($TERM=xterm,
 80x24); all had the same result for me.
 
 > 
 > Which vi version are you using, and which $TERM setting?
 
 vi from RELENG_2_1_5_RELEASE.  I don't doubt that the difference could be
 2.1.5 vs. current; I don't have a system running current here to try it
 here.  I checked out the vi from current as of last week and compiled it; 
 it exhibited the same problem.  I also checked out the vi from
 RELENG_2_1_0_RELEASE, and it had the same problem when compiled under
 2.1.5.  Note that the problem does not seem to be there on a 2.1.0 system
 using 2.1.0 vi, nor is it there when I copy the 2.1.0 binary to a 2.1.5
 system; when I copy a 2.1.5 binary to a 2.1.0 system the problem is still
 there.  It is present both on 2.1.5 compiled locally from the latest
 stable tree and on 2.1.5 installed via ftp from wcarchive.
 
 It appears that the bug is coming from somewhere other than the vi source
 (although the vi source still could be the thing that is broken) that is
 linked into the binary at compile time, not run time. 
 
 If you don't have a 2.1.5 system handy to try it on, try pulling the 2.1.5
 binary and running it under current.
 

From: Marc Slemko <marcs@valis.worldgate.com>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc: freebsd-gnats-submit@freefall.freebsd.org
Subject: Re: bin/1411: vi dumps core when using 'set list'
Date: Sun, 21 Jul 1996 17:31:10 -0600 (MDT)

 After further investigation, this problem appears to be the result of
 using -m486 in the CFLAGS while compiling vi.  If I compile without -m486,
 it works fine.  I am assuming that 2.1.5 was compiled with -m486 while
 2.1.0 wasn't...  Hopefully you can at least see the bug in current when
 you compile with -m486; if not, either the gods are smiling and something
 has made it go away or there is yet another difference in setups.
 
 Now the problem enters the gcc area of concern, which may mean it isn't
 worth bothering about at the moment since, as I seem to recall, there will
 likely be some gcc changes coming up.
 
 If 2.1.5 was compiled with -m486, and it causes this in vi, I am somewhat
 curious to see how many other similar things will pop up...
 
State-Changed-From-To: open->closed 
State-Changed-By: wosch 
State-Changed-When: Wed Sep 25 17:08:41 PDT 1996 
State-Changed-Why:  
gcc problem, which hopefully disappears in gcc  2.7.2  


Responsible-Changed-From-To: freebsd-bugs->peter 
Responsible-Changed-By: wosch 
Responsible-Changed-When: Wed Sep 25 17:08:41 PDT 1996 
Responsible-Changed-Why:  
>Unformatted:
