>Number:         9665
>Category:       bin
>Synopsis:       vi coredumps writing file after invokation with -r
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 23 02:12:01 2000
>Last-Modified:
>Originator:     John Hawkinson
>Organization:
	MIT
>Release:        NetBSD 1.4.2
>Environment:
	
System: NetBSD zorkmid.mit.edu 1.4.2 NetBSD 1.4.2 (ZORKMID) #1: Wed Mar 22 03:24:44 EST 2000 jhawk@zorkmid.mit.edu:/usr/src/sys/arch/i386/compile/ZORKMID i386


>Description:
	After receipt of mail reminding me, invoking "vi -r db_interface.c"
brings up my in-progress edit of the above. Attempting to write it to
a file (:w dbsnap) yields a vi core dump. This seems 100% reproducible
and I built a vi with symbols. Here's the stack:

(gdb) where
#0  0x400d1068 in _GLOBAL_OFFSET_TABLE_ ()
#1  0x400d001f in __errno ()
#2  0x400c0d72 in malloc ()
#3  0x400b9722 in __ovfl_get ()
#4  0x400b011b in __rec_ret ()
#5  0x400af28a in __rec_get ()
#6  0x1dc0c in db_get (sp=0x46000, lno=57, flags=1, pp=0xbfbfd400, 
    lenp=0xbfbfd404) at /usr/src/usr.bin/vi/build/../common/line.c:158
#7  0x1a6dc in ex_writefp (sp=0x46000, name=0x48390 "dbsnap3", fp=0x400dc538, 
    fm=0x430e4, tm=0x430ec, nlno=0xbfbfd4c0, nch=0xbfbfd4c4, silent=0)
    at /usr/src/usr.bin/vi/build/../ex/ex_write.c:329
#8  0x1bbb5 in file_write (sp=0x46000, fm=0x430e4, tm=0x430ec, 
    name=0x48390 "dbsnap3", flags=17)
    at /usr/src/usr.bin/vi/build/../common/exf.c:807
#9  0x1a5c0 in exwr (sp=0x46000, cmdp=0x43080, cmd=WRITE)
    at /usr/src/usr.bin/vi/build/../ex/ex_write.c:263
#10 0x1a21c in ex_write (sp=0x46000, cmdp=0x43080)
    at /usr/src/usr.bin/vi/build/../ex/ex_write.c:98
#11 0x71c9 in ex_cmd (sp=0x46000) at /usr/src/usr.bin/vi/build/../ex/ex.c:1352
#12 0x2a13d in v_ex (sp=0x46000, vp=0xbfbfd654)
    at /usr/src/usr.bin/vi/build/../vi/v_ex.c:461
#13 0x33b3f in vi (spp=0xbfbfd6e4) at /usr/src/usr.bin/vi/build/../vi/vi.c:235
#14 0x1f940 in editor (gp=0x43000, argc=3, argv=0xbfbfd8a0)
    at /usr/src/usr.bin/vi/build/../common/main.c:450
#15 0x2683 in main (argc=3, argv=0xbfbfd898)
    at /usr/src/usr.bin/vi/build/../cl/cl_main.c:117
(gdb) 

Doing so leaves behind a zero-length "dbsnap" file:

zorkmid% ls -l dbsnap
-rw-r--r--  1 jhawk  wheel  0 Mar 24 03:33 dbsnap

I don't know vi code terribly well and am not sure how to deal with
this, especially across function pointers. I'm also not terribly
experienced at weird shit malloc problems, the only real tool I've
used for this under NetBSD has been Electric Fence
(pkgsrc/devel/electricfence), but it seems to be broken under 1.4.2,
and gdb core dumps trying to analyze its brokenness (cf. bin/9664: gdb
can core dump unexpectedly).

I expect to spend some time trying to analyze the electric fence
core dump before giving up and submitting a PR for it, but
I don't know how to procede on the vi and gdb coredumps, hence this
pr and bin/9964.


>How-To-Repeat:
	
The recovery file looks normal:

zorkmid# cd /var/tmp/vi.recover/
zorkmid# ls -l 
total 147
-rw-------  1 jhawk  wheel    468 Mar 21 01:09 recover.00218d
-rwx------  1 root   wheel   5120 Mar  9 16:57 vi.00171b
-rwx------  1 root   wheel      0 Mar 14 18:53 vi.00173c
-rw-------  1 jhawk  wheel  11264 Mar 21 01:11 vi.00218b
-rwx------  1 jhawk  wheel  55296 Mar  8 03:45 vi.00227b
-rwx------  1 jhawk  wheel  77824 Mar  7 19:45 vi.00389b

but it is available upon request if it is thought to be relevent.

>Fix:
	Don't reboot the machine while editting the kernel source in vi.
	Don't try to recover with vi -r if you do.
	Don't use vi, use a real editor, or at least one that starts with
	  e, like ed, emacs, or ex[*].

---
[*] -- yeah, ex -r core dumps too. The stack trace looks about the same
without symbols, but then again, they all do.
>Audit-Trail:
>Unformatted: