Bug#292397: vim freezes on swap file prompt

[Bas Zoetekouw]

package vim
tag 292397 + upstream
tag 292397 + patch
thansk

Hi!

I've done some more debugging on this problem, and it seems only a few
of the vim variants are affected.  Specifically, I can reprocude the
problem using vim.gnome, vim.python and vim.perl, but vim.basic,
vim.gtk, vim.tiny, vim.lesstif, vim.ruby, vi.tcl and vim.full work fine.

Also, I've build a version of vim.perl with -ggdb3, and can reproduce
the problem there.  GDB gives the following backtrace after the freeze:

 | (gdb) bt
 | #0  0xffffe410 in __kernel_vsyscall ()
 | #1  0xb77fed6d in ___newselect_nocancel () from /lib/tls/i686/cmov/libc.so.6
 | #2  0x0815887b in RealWaitForChar (fd=0, msec=100, check_for_gpm=0xbfcd399c) at os_unix.c:4743
 | #3  0x081585c1 in WaitForChar (msec=100) at os_unix.c:4445
 | #4  0x08154b75 in mch_inchar (buf=0xbfcd3a4a "", maxlen=46, wtime=100, tb_change_cnt=0) at os_unix.c:328
 | #5  0x081b950f in ui_inchar (buf=0xbfcd3a4a "", maxlen=46, wtime=100, tb_change_cnt=0) at ui.c:189
 | #6  0x081185dd in get_keystroke () at misc1.c:3025
 | #7  0x08111f63 in do_dialog (type=2, title=0x81fb014 "VIM - ATTENTION", message=0x82fa060 "Swap file \"/tmp//%tmp%test.swp\" already exists!", buttons=0x81faf88 "&Open Read-Only\n&Edit anyway\n&Recover\n&Quit\n&Abort", dfltbutton=1, textfield=0x0) at message.c:3298
 | #8  0x0810971d in findswapname (buf=0x8234428, dirp=0xbfcd404c, old_fname=0x0) at memline.c:4107
 | #9  0x081039a2 in ml_open_file (buf=0x8234428) at memline.c:552
 | #10 0x08103ac4 in check_need_swap (newfile=1) at memline.c:604
 | #11 0x080d27d0 in readfile (fname=0x8235848 "/tmp/test", sfname=0x8235848 "/tmp/test", from=0, lines_to_skip=0, lines_to_read=2147483647, eap=0x0, flags=1) at fileio.c:642
 | #12 0x0806c4a2 in open_buffer (read_stdin=0, eap=0x0) at buffer.c:130
 | #13 0x080f770a in create_windows (parmp=0xbfcd43f0) at main.c:2378
 | #14 0x080f5589 in main (argc=2, argv=0xbfcd4534) at main.c:794

If I set a breakpoint on line 3026 of misc1.c (just after the
ui_inchar() call), I can verify that indeed a special key code is
returned (i.e. the cursor I pressed).  Specifically, the key code
returned is 0x80 0x8a 0x95 ("\eku", which I guess means the uparrow).
However, this key is not handled at all:  in the FEAT_MBYTE ifdef on
line 3084, the "continue" is called, and the loop progresses to the next
iteration, after which the key is never returned anymore by
get_keystroke().

So, the problem seems to be that the special sequences that are
generated by the cursor keys are mistaken for an incomplete multibyte
sequence; the check for such a special sequence is only done in
do_diaglog(), after get_keystroke() has returned.  

The following patch solves this, and works fine here.  Please include it
in the debian packages and also send it upstream.

--- vim/src/misc1.eerst	2006-04-13 13:45:37.000000000 +0200
+++ vim/src/misc1.c	2006-04-13 13:48:10.000000000 +0200
@@ -3082,7 +3082,9 @@
 	    }
 	}
 #ifdef FEAT_MBYTE
-	if (has_mbyte)
+	/* if n<0, this is a special key (eg cursor) which should 
+	 * not be mistaken for an incomplete multibyte sequence */
+	if (has_mbyte && n>=0) 
 	{
 	    if (MB_BYTE2LEN(n) > len)
 		continue;	/* more bytes to get */

Happy Vimming!

Bas.


PS: this was all tested using the 6.4+7.0c05-1 versions from
experimental.

-- 
Kind regards,
+--------------------------------------------------------------------+
| Bas Zoetekouw              | GPG key: 0644fab7                     |
|----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| bas at o2w.nl, bas at debian.org |              a2b1 2bae e41f 0644 fab7 |
+--------------------------------------------------------------------+