From owner-freebsd-stable Sun Jul 14 02:12:38 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA09881 for stable-outgoing; Sun, 14 Jul 1996 02:12:38 -0700 (PDT) Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA09863 for ; Sun, 14 Jul 1996 02:12:34 -0700 (PDT) Received: from ve6kik by scapa.cs.ualberta.ca with UUCP id <13079-3651>; Sun, 14 Jul 1996 03:12:26 -0700 Received: from alive.ampr.ab.ca by ve6kik.ampr.ab.ca with uucp (Smail3.1.28.1 #5) id m0ufMwP-000O4PC; Sun, 14 Jul 96 02:54 WET DST Received: by alive.ampr.ab.ca (Linux Smail3.1.29.1 #2) id m0ufLHo-000292C; Sun, 14 Jul 96 01:08 MDT Date: Sun, 14 Jul 1996 01:08:10 -0600 (MDT) From: Marc Slemko To: freebsd-stable@freebsd.org Subject: vi sometimes core dumps when scrolling with 'set list' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have noticed that sometimes vi will core dump when viewing a file with 'set list'. It seems to happen right when it tries to display the '$' at the end of a line which ends up being exactly 80 characters long before the '$'. For an example, try using /sys/scsi/st.c version 1.36.4.5; nothing special about this file, just a random example. Make sure you have your screen set for 80 columns. Do a ':set list', then scroll down. Line 185 displays fine for me (as long as you go down line by line), but going down one more line where the '$' should be for the end of line causes the core dump. This has been observed in stable as of a couple of days ago, and stable of a couple of weeks ago. 2.1.0-RELEASE doesn't seem to have this problem, but it wasn't compiled here. I don't know about current. This doesn't necessarily look to be a problem in vi, and it may not even be a real problem with anything except the way things are being compiled. Making slight modifications to the source (ie. changing one line, compiling, changing it back, then recompiling) or compile flags (once when I added a -g to get some debugging info the problem went away) can eliminate the problem. It is on two systems here running stable, built from independent source trees, but it may not be on all systems. There don't appear to have been any changes in the vi source tree between 2.1.0 and 2.1.5. I have not had time to actually look at the vi source much to see if it looks to be at fault. Any ideas? Some gdb output: Core was generated by `nvi'. Program terminated with signal 11, Segmentation fault. #0 0x312b6 in svi_line (sp=0x3f800, ep=0x45080, smp=0x5bdcc, 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=0x45080, smp=0x5bdcc, yp=0x0, xp=0x0) at /usr/var/tmp/vi/common/../svi/svi_line.c:376 #1 0x34695 in svi_sm_1up (sp=0x3f800, ep=0x45080) at /usr/var/tmp/vi/common/../svi/svi_smap.c:766 #2 0x34440 in svi_sm_up (sp=0x3f800, ep=0x45080, rp=0xefbfd48c, count=4, scmd=CNTRL_D, smp=0x5bc00) at /usr/var/tmp/vi/common/../svi/svi_smap.c:663 #3 0x340e4 in svi_sm_scroll (sp=0x3f800, ep=0x45080, rp=0xefbfd48c, count=12, scmd=CNTRL_D) at /usr/var/tmp/vi/common/../svi/svi_smap.c:535 #4 0x28644 in v_hpagedown (sp=0x3f800, ep=0x45080, vp=0xefbfd464) at /usr/var/tmp/vi/common/../vi/v_scroll.c:332 #5 0x2e48f in vi (sp=0x3f800, ep=0x45080) at /usr/var/tmp/vi/common/../vi/vi.c:200 #6 0x32f24 in svi_screen_edit (sp=0x3f800, ep=0x45080) at /usr/var/tmp/vi/common/../svi/svi_screen.c:225 #7 0x580c in main (argc=2, argv=0xefbfda24) at main.c:435 -- Marc Slemko 1:342/1003@fidonet marcs@alive.ampr.ab.ca marcs@alive.ersys.edmonton.ab.ca