Ubuntu

Vim locks up while editing a specific file (file attached)

Reported by Anderson Lizardo on 2006-10-29
8
Affects Status Importance Assigned to Milestone
vim (Debian)
Fix Released
Unknown
vim (Ubuntu)
Undecided
Colin Watson

Bug Description

Binary package hint: vim

Vim is locking up (i.e. it hangs and consumes 100% CPU) when the following steps are done:

1) Open the attached "vim_testcase" file with vim:

$ vim vim_testcase

2) Enable syntax highlight, if not enabled yet, by typing in normal mode:

:syntax on

3) Go to line 89 (either by typing ":89" while in normal mode or using down arrow key)

4) Pass the text cursor over the closing parenthesis on this line using the left/right arrow keys.

5) Vim should lock up and the only way to close it is by killing its process

System information:
- Ubuntu 6.10
- vim 7.0-035+1ubuntu5

The testcase file will follow.

Anderson Lizardo (lizardo) wrote :

Attached testcase file.

Constantine Evans (cevans) wrote :

I've confirmed this in Edgy. I will look into this upstream tomorrow.

Changed in vim:
status: Unconfirmed → Confirmed

> 5) Vim should lock up and the only way to close it is by killing its process

As a workaround, just press ctrl+c, vim will come back to life.

Anderson Lizardo (lizardo) wrote :

FWIW, this bug still applies to Edgy, given that there were no updates to the vim package since then. I plan to test it on Feisty once I have it installed, but if anyone could do this that would be nice.

Download full text (6.6 KiB)

I can also reproduce this bug with the latest version of vim (vim-7.1.156)
which I downloaded from cvs and compiled from sources.

I move cursor from left to right over parenthese at line 89 (it's fine)
but when I move cursor from right to left over parenthese, vim
then takes 100% of CPU. I waited several minutes, so it
looks like it's an endless loop (or something that would be
very slow!)

If I attached with gdb to the running process, I see the stack trace
(quite deep) at given time (when it loops forever):

#0 0x0811cff4 in utf_ptr2char (p=0x82bf771 "\tfor i in $(qemu_bios_files); do \\") at mbyte.c:1377
#1 0x0815b428 in regmatch (scan=0x82a13d5 "\005") at regexp.c:3795
#2 0x0815b091 in regtry (prog=0x82a1380, col=0) at regexp.c:3599
#3 0x0815ae41 in vim_regexec_both (line=0x82bf771 "\tfor i in $(qemu_bios_files); do \\", col=0) at regexp.c:3469
#4 0x0815aa5b in vim_regexec_multi (rmp=0xbf8de7d4, win=0x822d208, buf=0x822e188, lnum=69, col=0) at regexp.c:3329
#5 0x0819cea9 in syn_regexec (rmp=0xbf8de7d4, lnum=69, col=0) at syntax.c:3098
#6 0x0819b3c6 in syn_current_attr (syncing=0, displaying=0, can_spell=0x0) at syntax.c:2000
#7 0x0819abf5 in syn_finish_line (syncing=0) at syntax.c:1694
#8 0x0819914e in syntax_start (wp=0x822d208, lnum=80) at syntax.c:565
#9 0x081a2536 in syn_get_id (wp=0x822d208, lnum=80, col=11, trans=0, spellp=0x0) at syntax.c:6101
#10 0x080870f5 in f_synID (argvars=0xbf8dead4, rettv=0xbf8deec4) at eval.c:15691
#11 0x0807b8b7 in call_func (name=0x82a0892 "synID", len=5, rettv=0xbf8deec4, argcount=3, argvars=0xbf8dead4,
    firstline=80, lastline=80, doesrange=0xbf8debd8, evaluate=1, selfdict=0x0) at eval.c:7628
#12 0x0807b3ea in get_func_tv (name=0x82a0892 "synID", len=5, rettv=0xbf8deec4, arg=0xbf8def6c, firstline=80,
    lastline=80, doesrange=0xbf8debd8, evaluate=1, selfdict=0x0) at eval.c:7446
#13 0x08077a77 in eval7 (arg=0xbf8def6c, rettv=0xbf8deec4, evaluate=1) at eval.c:4697
#14 0x080775ad in eval6 (arg=0xbf8def6c, rettv=0xbf8deec4, evaluate=1) at eval.c:4466
#15 0x080772ea in eval5 (arg=0xbf8def6c, rettv=0xbf8deec4, evaluate=1) at eval.c:4335
#16 0x08076a04 in eval4 (arg=0xbf8def6c, rettv=0xbf8deec4, evaluate=1) at eval.c:4067
#17 0x0807685c in eval3 (arg=0xbf8def6c, rettv=0xbf8deec4, evaluate=1) at eval.c:3979
#18 0x080766e8 in eval2 (arg=0xbf8def6c, rettv=0xbf8deec4, evaluate=1) at eval.c:3908
#19 0x0807651e in eval1 (arg=0xbf8def6c, rettv=0xbf8deec4, evaluate=1) at eval.c:3833
#20 0x0807b35a in get_func_tv (name=0x82a0888 "synIDattr(synID", len=9, rettv=0xbf8df2cc, arg=0xbf8df2a0,
    firstline=80, lastline=80, doesrange=0xbf8defc8, evaluate=1, selfdict=0x0) at eval.c:7431
#21 0x08077a77 in eval7 (arg=0xbf8df2a0, rettv=0xbf8df2cc, evaluate=1) at eval.c:4697
#22 0x080775ad in eval6 (arg=0xbf8df2a0, rettv=0xbf8df2cc, evaluate=1) at eval.c:4466
#23 0x080772ea in eval5 (arg=0xbf8df2a0, rettv=0xbf8df2cc, evaluate=1) at eval.c:4335
#24 0x08076a04 in eval4 (arg=0xbf8df2a0, rettv=0xbf8df2cc, evaluate=1) at eval.c:4067
#25 0x0807685c in eval3 (arg=0xbf8df2a0, rettv=0xbf8df2cc, evaluate=1) at eval.c:3979
#26 0x080766e8 in eval2 (arg=0xbf8df2a0, rettv=0xbf8df2cc, evaluate=1) at eval.c:3908
#27 0x0807651e...

Read more...

I did a bit of debugging with latest vim-7.1 (patches 1-166).

I found that vim loops forever in a while(...)
loop in syntax.c in function syntax_start():

syntax.c:

 562 while (current_lnum < lnum)
 563 {
 ...
 ...
 596 load_current_state(prev);
 ...
 ...
 609 line_breakcheck();
 610 if (got_int)
 611 {
 612 current_lnum = lnum;
 613 break;
 614 }
 615 }

This while loop never ends with attached "vim_testcase" file.
Adding some printf(), I can see that:

  - Before entering above while loop:
      - current_lnum == 65
      - lnum == 80

  - Then when iterating in the while loop:
      - lnum remains unchanged (80)
      - current_lnum becomes:

        65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
        65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
        65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
        etc.

current_lnum never reaches lnum (80) so loop never ends.

current_lnum goes from 78 to 65 when calling load_current_state(prev)
at line 596.

I do not understand the idea behind load_current_state() and
store_current_state() to go beyond and come up with fix for this.

I posted this to the vim_dev mailing list:

http://groups.google.com/group/vim_dev/browse_thread/thread/157f265102c48127/5550df9950274543?lnk=st&q=#5550df9950274543

Patch 7.1.227 of Vim fixes this issue. Bug can be marked as fixed when Ubuntu uses a version >= 7.1.227.

VF (vfiend) on 2008-03-23
Changed in vim:
status: Confirmed → Fix Committed
Colin Watson (cjwatson) wrote :

Thanks for following this up, Dominique. I've just uploaded 1:7.1.293-2ubuntu1 to intrepid, which should contain this fix.

Changed in vim:
assignee: nobody → kamion
status: Fix Committed → Fix Released
Changed in vim:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.