George V. Reilly wrote: > I have a reproable crash, apparently due to syntax highlighting memory > corruption. > > The stack traces below were taken with WinDbg while running Vim > 7.2.108 on Windows. > MacVim is also horribly slow with jquery.vim and eventually crashes. > > Download the syntax highlighting file for jQuery, > http://www.vim.org/scripts/script.php?script_id=2416 > > Download jQuery.js, http://jqueryjs.googlecode.com/files/jquery-1.3.2.js > > Run > gvim -u NONE jQuery.js > :se nocp > :syn on > > The regular Javascript syntax highlighting is fine. > Move around, everything is good. > > G > :so jquery.vim > > Watch your CPU meter max out and memory usage grow for many seconds. > If you're running gvim under a debugger, break in every so often and > look at the current call stack. It'll be something like this > (I saw fastcopy repeatedly). > > 0:001> ~0k > ChildEBP RetAddr > 0012f6bc 0040fe6b gvim!fastcopy_I+0x5a > 0012f6cc 00424490 gvim!_VEC_memcpy+0x52 > 0012f6ec 004ca55b gvim!_VEC_memzero+0x36 > 0012f708 0045d9ed gvim!ga_grow+0x5b > [d:\projects\vimsrc\vim7\src\misc2.c @ 1989] > 0012f714 0045dd81 gvim!push_current_state+0xd > [d:\projects\vimsrc\vim7\src\syntax.c @ 2727] > 0012f728 0045e761 gvim!push_next_match+0x21 > [d:\projects\vimsrc\vim7\src\syntax.c @ 2379] > 0012f878 0045eab1 gvim!syn_current_attr+0x811 > [d:\projects\vimsrc\vim7\src\syntax.c @ 2171] > 0012f898 00460786 gvim!syn_finish_line+0x21 > [d:\projects\vimsrc\vim7\src\syntax.c @ 1693] > 0012f8bc 0048baf3 gvim!syntax_start+0x1f6 > [d:\projects\vimsrc\vim7\src\syntax.c @ 565] > 0012fb50 0048fb20 gvim!win_line+0x1d3 > [d:\projects\vimsrc\vim7\src\screen.c @ 2727] > 0012fbec 00492656 gvim!win_update+0x1420 > [d:\projects\vimsrc\vim7\src\screen.c @ 1768] > 0012fc0c 004f54be gvim!update_screen+0x496 > [d:\projects\vimsrc\vim7\src\screen.c @ 522] > 0012fc88 004f842c gvim!main_loop+0x24e > [d:\projects\vimsrc\vim7\src\main.c @ 1109] > 0012fdcc 00573dc2 gvim!VimMain+0xbbc > [d:\projects\vimsrc\vim7\src\main.c @ 942] > 0012fef0 0040af6c gvim!WinMain+0x92 > [d:\projects\vimsrc\vim7\src\os_w32exe.c @ 131] > [...] > 0:000> g > > Or this: > > 0:001> ~0k > ChildEBP RetAddr > 0012f728 0045e458 gvim!did_match_already+0x35 > [d:\projects\vimsrc\vim7\src\syntax.c @ 2350] > 0012f878 0045eab1 gvim!syn_current_attr+0x508 > [d:\projects\vimsrc\vim7\src\syntax.c @ 2040] > 0012f898 00460786 gvim!syn_finish_line+0x21 > [d:\projects\vimsrc\vim7\src\syntax.c @ 1693] > 0012f8bc 0048baf3 gvim!syntax_start+0x1f6 > [d:\projects\vimsrc\vim7\src\syntax.c @ 565] > 0012fb50 0048fb20 gvim!win_line+0x1d3 > [d:\projects\vimsrc\vim7\src\screen.c @ 2727] > 0012fbec 00492656 gvim!win_update+0x1420 > [d:\projects\vimsrc\vim7\src\screen.c @ 1768] > 0012fc0c 004f54be gvim!update_screen+0x496 > [d:\projects\vimsrc\vim7\src\screen.c @ 522] > 0012fc88 004f842c gvim!main_loop+0x24e > [d:\projects\vimsrc\vim7\src\main.c @ 1109] > 0012fdcc 00573dc2 gvim!VimMain+0xbbc > [d:\projects\vimsrc\vim7\src\main.c @ 942] > 0012fef0 0040af6c gvim!WinMain+0x92 > [d:\projects\vimsrc\vim7\src\os_w32exe.c @ 131] > [...] > 0:001> g > > Eventually, the prompt will come back. > Memory usage will be huge (for Vim), about 130MB. > > Go somewhere else in the file, such as ":3333". > Try holding down the Enter key. > Eventually, you should see an Access violation. > > (2218.18ec): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000000 ebx=01df59e8 ecx=00000000 edx=01df6868 esi=025c11cc > edi=ffe14700 > eip=0045e08c esp=0012f730 ebp=00000000 iopl=0 nv up ei ng > nz na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010286 > gvim!syn_current_attr+0x13c: > 0045e08c 394f44 cmp dword ptr [edi+44h],ecx > ds:0023:ffe14744=???????? > 0:000> kp > ChildEBP RetAddr > 0012f878 0045eab1 gvim!syn_current_attr(int syncing = <Memory > access error>, int displaying = <Memory access error>, int * can_spell > = <Memory access error>, int keep_state = <Memory access error>)+0x13c > [d:\projects\vimsrc\vim7\src\syntax.c @ 1888] > 0012f898 00460786 gvim!syn_finish_line(int syncing = > -2013440)+0x21 [d:\projects\vimsrc\vim7\src\syntax.c @ 1693] > 0012f8bc 0048baf3 gvim!syntax_start(struct window_S * wp = > 0x00000000, long lnum = 3313)+0x1f6 > [d:\projects\vimsrc\vim7\src\syntax.c @ 565] > 0012fb50 0048fb20 gvim!win_line(struct window_S * wp = 0x00000000, > long lnum = <Memory access error>, int startrow = <Memory access > error>, int endrow = <Memory access error>, int nochange = <Memory > access error>)+0x1d3 [d:\projects\vimsrc\vim7\src\screen.c @ 2727] > 0012fbec 00492656 gvim!win_update(struct window_S * wp = > 0x01df59e8)+0x1420 [d:\projects\vimsrc\vim7\src\screen.c @ 1768] > 0012fc0c 004f54be gvim!update_screen(int type = 10)+0x496 > [d:\projects\vimsrc\vim7\src\screen.c @ 522] > 0012fc88 004f842c gvim!main_loop(int cmdwin = 0, int noexmode = > 0)+0x24e [d:\projects\vimsrc\vim7\src\main.c @ 1109] > 0012fdcc 00573dc2 gvim!VimMain(void)+0xbbc > [d:\projects\vimsrc\vim7\src\main.c @ 942] > 0012fef0 0040af6c gvim!WinMain(struct HINSTANCE__ * hInstance = > 0x769d4911, struct HINSTANCE__ * hPrevInst = 0x7ffd3000, char * > lpszCmdLine = 0x0012ffd4 "???", int nCmdShow = 1997857974)+0x92 > [d:\projects\vimsrc\vim7\src\os_w32exe.c @ 131] > 0012ff88 769d4911 gvim!__tmainCRTStartup(void)+0x177 > [f:\qfe\vctools\crt_bld\self_x86\crt\src\crt0.c @ 324] > WARNING: Stack unwind information not available. Following frames > may be wrong. > 0012ff94 7714e4b6 kernel32!BaseThreadInitThunk+0x12 > 0012ffd4 7714e489 ntdll!RtlInitializeExceptionChain+0x63 > 0012ffec 00000000 ntdll!RtlInitializeExceptionChain+0x36 > > I don't have time to look into this further today. > -- > /George V. Reilly [email protected] > http://www.georgevreilly.com/blog http://blogs.cozi.com/tech
Hi I can reproduce this bug on Linux with latest Vim-7.2.166 on Linux x86 & Linux x86_64. Steps to reproduce: 1/ download "jquery.vim" available at: http://www.vim.org/scripts/script.php?script_id=2416 2/ download "jquery-1.3.2.js" available at: http://jqueryjs.googlecode.com/files/jquery-1.3.2.js 3/ start vim with: vim -u NONE jquery-1.3.2.js 4/ :set nocp :syn on :so jquery.vim 5/ Go to end of file (jquery-1.3.2.js) with: G 6/ Observe that Vim takes 100% of CPU and that memory usage is slowly increasing. 7/ Wait for a few minutes, until eventually Vim crashes with "seg fault" (Vim uses 100% of CPU for 2 minutes or so on my machine before it crashes). Now if I attach with gdb while Vim takes 100% of the CPU (before it crashes), I see that current_state.ga_len keeps increasing and the stack often looks like this: (gdb) bt #0 0x00007ff4e13b50bb in ?? () from /lib64/libc.so.6 #1 0x00007ff4e13b32ca in memmove () from /lib64/libc.so.6 #2 0x00000000004d99ab in ga_grow (gap=0x82d2a0, n=3) at misc2.c:2001 #3 0x00000000005695ab in push_current_state (idx=19) at syntax.c:2727 #4 0x00000000005689a8 in push_next_match (cur_si=0x7ff4db3341d0) at syntax.c:2379 #5 0x0000000000568392 in syn_current_attr (syncing=0, displaying=0, can_spell=0x0, keep_state=0) at sy ntax.c:2171 #6 0x00000000005675f2 in syn_finish_line (syncing=0) at syntax.c:1693 #7 0x00000000005653a4 in syntax_start (wp=0x83b850, lnum=4314) at syntax.c:564 #8 0x0000000000531035 in win_line (wp=0x83b850, lnum=4314, startrow=0, endrow=63, nochange=1) at scree n.c:2728 #9 0x000000000052f055 in win_update (wp=0x83b850) at screen.c:1765 #10 0x000000000052c912 in update_screen (type=10) at screen.c:522 #11 0x00000000004a935a in main_loop (cmdwin=0, noexmode=0) at main.c:1109 #12 0x00000000004a8ff4 in main (argc=4, argv=0x7fffebc40d88) at main.c:939 (gdb) p current_state $2 = { ga_len = 37561, ga_maxlen = 37564, ga_itemsize = 136, ga_growsize = 3, ga_data = 0x7ff4dae55010 } Whenever I continue in gdb, and press CTRL-C to look at current_state, I see that current_state.ga_len keeps increasing steadily until eventually Vim crashes (gdb) c Continuing. (press Ctrl-C) (gdb) bt #0 0x00007ff4e13b3dad in memset () from /lib64/libc.so.6 #1 0x00000000004d87b9 in alloc_clear (size=5744368) at misc2.c:779 #2 0x00000000004d9954 in ga_grow (gap=0x82d2a0, n=3) at misc2.c:1995 #3 0x00000000005695ab in push_current_state (idx=19) at syntax.c:2727 #4 0x00000000005689a8 in push_next_match (cur_si=0xddf3280) at syntax.c:2379 #5 0x0000000000568392 in syn_current_attr (syncing=0, displaying=0, can_spell=0x0, keep_state=0) at syntax.c:2171 #6 0x00000000005675f2 in syn_finish_line (syncing=0) at syntax.c:1693 #7 0x00000000005653a4 in syntax_start (wp=0x83b850, lnum=4314) at syntax.c:564 #8 0x0000000000531035 in win_line (wp=0x83b850, lnum=4314, startrow=0, endrow=63, nochange=1) at screen.c:2728 #9 0x000000000052f055 in win_update (wp=0x83b850) at screen.c:1765 #10 0x000000000052c912 in update_screen (type=10) at screen.c:522 #11 0x00000000004a935a in main_loop (cmdwin=0, noexmode=0) at main.c:1109 #12 0x00000000004a8ff4 in main (argc=4, argv=0x7fffebc40d88) at main.c:939 (gdb) p current_state $4 = { ga_len = 42235, ga_maxlen = 42235, ga_itemsize = 136, ga_growsize = 3, ga_data = 0xd878db0 } Eventually, it seems that current_state.ga_len stops increasing and remains at 50546: (gdb) p current_state $15 = { ga_len = 50546, ga_maxlen = 50548, ga_itemsize = 136, ga_growsize = 3, ga_data = 0x165a06e0 } And Vim crashes just a few seconds later: Program received signal SIGSEGV, Segmentation fault. Looking at the core file with gdb, I see the following post mortem stack trace: (gdb) bt #0 0x0000000000567a20 in syn_current_attr (syncing=0, displaying=0, can_spell=0x0, keep_state=0) at syntax.c:1887 #1 0x00000000005675f2 in syn_finish_line (syncing=0) at syntax.c:1693 #2 0x00000000005653a4 in syntax_start (wp=0x83b850, lnum=4322) at syntax.c:564 #3 0x0000000000531035 in win_line (wp=0x83b850, lnum=4322, startrow=0, endrow=62, nochange=1) at screen.c:2728 #4 0x000000000052f055 in win_update (wp=0x83b850) at screen.c:1765 #5 0x000000000052c912 in update_screen (type=10) at screen.c:522 #6 0x00000000004a935a in main_loop (cmdwin=0, noexmode=0) at main.c:1109 #7 0x00000000004a8ff4 in main (argc=4, argv=0x7fff6f3b4508) at main.c:939 syntax.c: 1882 if (current_state.ga_len) 1883 cur_si = &CUR_STATE(current_state.ga_len - 1); 1884 else 1885 cur_si = NULL; 1886 1887> if (syn_buf->b_syn_containedin || cur_si == NULL 1888 || cur_si->si_cont_list != NULL) 1889 { syn_buf pointer looks OK as far as I can tell, but cur_si pointer is an invalid pointer: (gdb) p syn_buf->b_syn_containedin $3 = 0 (gdb) p cur_si $4 = (stateitem_T *) 0xffffffffffdf7b50 (gdb) p cur_si->si_cont_list Cannot access memory at address 0xffffffffffdf7bc0 (cur_si is a negative value) (gdb) p (int)cur_si $2 = -2131120 cur_si is initialized just a few lines above the crash in syntax.c:1883 from current_state.ga_len. Looking at current_state, I see this: (gdb) p current_state $5 = { ga_len = -15669, ga_maxlen = 0, ga_itemsize = 136, ga_growsize = 3, ga_data = 0x0 } Notice that current_state.ga_len has become a negative value and that ga_data is NULL. Running the same steps with Valgrind memcheck does not give much more information: ==2824== Invalid read of size 8 ==2824== at 0x567A20: syn_current_attr (syntax.c:1887) ==2824== by 0x567809: get_syntax_attr (syntax.c:1771) ==2824== by 0x56FF6E: syn_get_id (syntax.c:6134) ==2824== by 0x4464B8: f_synID (eval.c:16556) ==2824== by 0x43A899: call_func (eval.c:8101) ==2824== by 0x43A3AC: get_func_tv (eval.c:7918) ==2824== by 0x4362D2: eval7 (eval.c:5010) ==2824== by 0x435B9D: eval6 (eval.c:4677) ==2824== by 0x435790: eval5 (eval.c:4493) ==2824== by 0x434D14: eval4 (eval.c:4188) ==2824== by 0x434B79: eval3 (eval.c:4100) ==2824== by 0x434A01: eval2 (eval.c:4029) ==2824== by 0x434842: eval1 (eval.c:3954) ==2824== by 0x43A304: get_func_tv (eval.c:7903) ==2824== by 0x4362D2: eval7 (eval.c:5010) ==2824== by 0x435B9D: eval6 (eval.c:4677) ==2824== by 0x435790: eval5 (eval.c:4493) ==2824== by 0x434D14: eval4 (eval.c:4188) ==2824== by 0x434B79: eval3 (eval.c:4100) ==2824== by 0x434A01: eval2 (eval.c:4029) ==2824== by 0x434842: eval1 (eval.c:3954) ==2824== by 0x4347AF: eval0 (eval.c:3911) ==2824== by 0x44F17E: ex_return (eval.c:21498) ==2824== by 0x4662F1: do_one_cmd (ex_docmd.c:2622) ==2824== by 0x463A98: do_cmdline (ex_docmd.c:1096) ==2824== by 0x44EB2E: call_user_func (eval.c:21293) ==2824== by 0x43A772: call_func (eval.c:8072) ==2824== by 0x43A3AC: get_func_tv (eval.c:7918) ==2824== by 0x4362D2: eval7 (eval.c:5010) ==2824== by 0x435B9D: eval6 (eval.c:4677) ==2824== Address 0xffffffffffe0e1d0 is not stack'd, malloc'd or (recently) free 'd ==2824== ==2824== Process terminating with default action of signal 11 (SIGSEGV): dumping core I'll try to investigate further, but so far I have not found how to fix this. -- Dominique --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
