>Number:         5108
>Category:       bin
>Synopsis:       vi SEGVs when it's in insert mode and gets HUPped
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar  3 09:35:01 1998
>Last-Modified:
>Originator:     Chris G. Demetriou
>Organization:
Kernel Hackers 'r' Us
>Release:        NetBSD 1.3, NetBSD-current as of March 3, 1998
>Environment:
System: NetBSD brick.demetriou.com 1.3D NetBSD 1.3D (BRICK) #36: Wed Feb 18 21:00:25 PST 1998 cgd@brick.demetriou.com:/usr/src/sys/arch/i386/compile/BRICK i386
(I built a vi out of fresh -current sources, and tested the vi on a few 1.3
systems as well.)

>Description:
	If vi receives a SIGHUP (at least; maybe other signals) when it's
	in input mode, instead of cleaning up gracefully, sending a recovery
	message, etc., it just seg-faults.  (That's kind of annoying if
	you're trying to do work over a low-throughput/reliability link.
	Even if your connection loses, you should expect vi's recovery
	mechanism to do the right thing.)

	(This bug was noticed while researching the "vi recover file
	notificaton just keeps on notifying" PR.  I tried to get vi to
	generate a recovery file for an editor session, but to my surprise
	I'd left the editor in input mode and it cored!)

>How-To-Repeat:
	vi /tmp/foo.  Get into insert mode, type a bit (or don't type
	anything at all; it doesn't matter as long as you're in insert mode).
	(Don't exit insert mode!!!)

	Using another window, find the pid of the vi process, and kill -HUP
	it.

	Note how the vi seg-faulted, didn't send out any recovery messages
	re: the contents of the file you were modifying, etc.

>Fix:
	Unknown.  ("I didn't even try.")
>Audit-Trail:
>Unformatted: