On Monday, May 9, 2016 at 8:38:59 AM UTC+2, Bram Moolenaar wrote: > Jeroen Budts wrote: > > > On Sunday, May 8, 2016 at 11:15:12 PM UTC+2, Jeroen Budts wrote: > > > On Sunday, May 8, 2016 at 9:49:09 PM UTC+2, Bram Moolenaar wrote: > > > > Dominique Pellé wrote: > > > > > > > > > > Jeroen Budts <[email protected]> wrote: > > > > > > > > > > > >> The crash seems to be a bit random, but I trigger it as follows: > > > > > >> 1. I switch to the tiling layout, which is the second layout in > > > > > >> default Awesome. > > > > > >> 2. Then I start Gvim and open a file, such as > > > > > >> /etc/xdg/awesome/rc.lua > > > > > >> 3. Then I start another Gvim and open another file (a markdown > > > > > >> file for example) > > > > > >> 4. Then I resize the master pane. Sometimes I have to do it just a > > > > > >> few times, sometimes I have to hit Mod4+h and Mod4+l at random 50 > > > > > >> times and/or switch layouts a few times. > > > > > >> 5. One of both Gvim instances crashes. > > > > > >> > > > > > >> I also tried to trigger the crash when Gvim is floating (Mod4 + > > > > > >> Control + Space) and resizing Gvim with the mouse (Mod4+button3), > > > > > >> but I can't seem to trigger the crash in this scenario. > > > > > >> > > > > > >> Kind regards, > > > > > >> Jeroen > > > > > > > > > > > > Hi Jeroen > > > > > > > > > > > > I finally successfully reproduced the crash on xubuntu-15.10 > > > > > > (32-bits x86) > > > > > > using awesome in tiled mode and all your plugins. > > > > > > > > > > > > I was running gvim-7.4.1817 (huge, gtk3 gui). I had 2 gvim > > > > > > instances: > > > > > > - one with /etc/xdg/awesome/rc.lua opened > > > > > > - another with $HOME/.bashrc opened. This instance of gvim crashed > > > > > > after several resize. > > > > > > > > > > > > I don't recall exactly which keys in used in to resize in awesome, > > > > > > but next time but I think it was Mod+h and Mod+l (where mod > > > > > > is the Windows key). > > > > > > > > > > > > Here is the backtrace in gdb where it crashed: > > > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > > 0x081e147f in in_id_list (cur_si=0x895d308, list=0x3ff00000, > > > > > > ssp=0x8a61498, contained=0) at syntax.c:6199 > > > > > > (gdb) bt > > > > > > #0 0x081e147f in in_id_list (cur_si=0x895d308, list=0x3ff00000, > > > > > > ssp=0x8a61498, contained=0) at syntax.c:6199 > > > > > > #1 0x081d9728 in syn_current_attr (syncing=0, displaying=1, > > > > > > can_spell=0xbfffeda4, keep_state=0) at syntax.c:2096 > > > > > > #2 0x081d90d5 in get_syntax_attr (col=4, can_spell=0xbfffeda4, > > > > > > keep_state=0) at syntax.c:1868 > > > > > > #3 0x081e1b6c in syn_get_id (wp=0x82cbed8, lnum=60, col=4, trans=0, > > > > > > spellp=0xbfffeda4, keep_state=0) at syntax.c:6489 > > > > > > #4 0x081b9f59 in spell_move_to (wp=0x82cbed8, dir=1, allwords=1, > > > > > > curline=1, attrp=0xbfffee60) at spell.c:2288 > > > > > > #5 0x0819bb7f in win_line (wp=0x82cbed8, lnum=60, startrow=3, > > > > > > endrow=4, nochange=0) at screen.c:3449 > > > > > > #6 0x08196e97 in update_single_line (wp=0x82cbed8, lnum=60) at > > > > > > screen.c:824 > > > > > > #7 0x08232516 in main_loop (cmdwin=0, noexmode=0) at main.c:1306 > > > > > > #8 0x08231fba in main (argc=3, argv=0xbffff434) at main.c:1051 > > > > > > > > > > > > (gdb) p list > > > > > > $2 = (short *) 0x3ff00000 > > > > > > > > > > > > (gdb) p *list > > > > > > Cannot access memory at address 0x3ff00000 > > > > > > > > > > > > Code where it crashes in syntax.c:6199: > > > > > > > > > > > > 6194 /* > > > > > > 6195 * If the first item is "ALLBUT", return TRUE if "id" is > > > > > > NOT in the > > > > > > 6196 * contains list. We also require that "id" is at the > > > > > > same > > > > > > ":syn include" > > > > > > 6197 * level as the list. > > > > > > 6198 */ > > > > > > !! 6199 item = *list; > > > > > > > > > > > > I have not had the time to debug yet, but I'll find time later. > > > > > > I will try to see if it happens with vim in terminal. > > > > > > I'll also try to remove some plugins to make it easier to reproduce, > > > > > > but if you can help narrowing down yourself which plugin causes it, > > > > > > that would save time. > > > > > > > > > > > > Regards > > > > > > Dominique > > > > > > > > > > Hi > > > > > > > > > > I've built vim-7.4.1822 (huge, gtk3 gui) with asan, which can be done > > > > > by > > > > > uncommenting this line in vim/src/Makefile: > > > > > > > > > > SANITIZER_CFLAGS = -g -O0 -fsanitize=address -fno-omit-frame-pointer > > > > > > > > > > vim then crashes very quickly when using awesome window > > > > > manager after: > > > > > - starting 2 vim instances in 2 terminals using: > > > > > $ vim -f -g 2> log1 /etc/xdg/awesome/rc.lua # in terminal 1 > > > > > $ vim -f -g 2> log2 /etc/xdg/awesome/rc.lua # in terminal 2 > > > > > - then enter tiling mode in awesome (by pressing Mod+Space) > > > > > - then resize windows with Mod+h and/or Mod+l (where > > > > > Mod is the Windows key). > > > > > > > > > > One of the vim instance crashes, and asan gives this error > > > > > on log1 or log2 file: > > > > > > > > > > ================================================================= > > > > > ==2354==ERROR: AddressSanitizer: heap-use-after-free on address > > > > > 0xac2634b1 at pc 0x082e0bd6 bp 0xbf95aff8 sp 0xbf95afe8 > > > > > READ of size 1 at 0xac2634b1 thread T0 > > > > > #0 0x82e0bd5 in utf_ptr2char /home/pel/sb/vim/src/mbyte.c:1684 > > > > > #1 0x83f3e92 in nfa_regmatch > > > > > /home/pel/sb/vim/src/regexp_nfa.c:5613 > > > > > #2 0x83fb72a in nfa_regtry /home/pel/sb/vim/src/regexp_nfa.c:6964 > > > > > #3 0x83fcc40 in nfa_regexec_both > > > > > /home/pel/sb/vim/src/regexp_nfa.c:7156 > > > > > #4 0x83fd4f7 in nfa_regexec_multi > > > > > /home/pel/sb/vim/src/regexp_nfa.c:7366 > > > > > #5 0x83fdefc in vim_regexec_multi > > > > > /home/pel/sb/vim/src/regexp.c:8177 > > > > > #6 0x84c4e13 in syn_regexec /home/pel/sb/vim/src/syntax.c:3307 > > > > > #7 0x84be442 in syn_current_attr > > > > > /home/pel/sb/vim/src/syntax.c:2116 > > > > > #8 0x84bd0f4 in get_syntax_attr /home/pel/sb/vim/src/syntax.c:1868 > > > > > #9 0x8415eeb in win_line /home/pel/sb/vim/src/screen.c:4385 > > > > > #10 0x8401b40 in update_single_line > > > > > /home/pel/sb/vim/src/screen.c:824 > > > > > #11 0x85bce57 in main_loop /home/pel/sb/vim/src/main.c:1306 > > > > > #12 0x85bc4f6 in main /home/pel/sb/vim/src/main.c:1051 > > > > > #13 0xb63e073d in __libc_start_main > > > > > (/lib/i386-linux-gnu/libc.so.6+0x1873d) > > > > > #14 0x8052970 (/home/pel/sb/vim/src/vim+0x8052970) > > > > > > > > > > 0xac2634b1 is located 1 bytes inside of 2-byte region > > > > > [0xac2634b0,0xac2634b2) > > > > > freed by thread T0 here: > > > > > #0 0xb721bbf4 in free > > > > > (/usr/lib/i386-linux-gnu/libasan.so.2+0x96bf4) > > > > > #1 0x82b9760 in vim_free /home/pel/sb/vim/src/misc2.c:1695 > > > > > #2 0x81267af in clear_tv /home/pel/sb/vim/src/eval.c:22433 > > > > > #3 0x80d3bd0 in eval4 /home/pel/sb/vim/src/eval.c:4709 > > > > > #4 0x80d23e0 in eval3 /home/pel/sb/vim/src/eval.c:4382 > > > > > #5 0x80d1f4b in eval2 /home/pel/sb/vim/src/eval.c:4314 > > > > > #6 0x80d19b2 in eval1 /home/pel/sb/vim/src/eval.c:4242 > > > > > #7 0x80d177e in eval0 /home/pel/sb/vim/src/eval.c:4202 > > > > > #8 0x80c246e in eval_to_bool /home/pel/sb/vim/src/eval.c:1369 > > > > > #9 0x81b5053 in ex_else /home/pel/sb/vim/src/ex_eval.c:1013 > > > > > #10 0x81821a2 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2921 > > > > > #11 0x817a626 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1107 > > > > > #12 0x8136248 in call_user_func /home/pel/sb/vim/src/eval.c:25475 > > > > > #13 0x80e5d43 in call_func /home/pel/sb/vim/src/eval.c:9158 > > > > > #14 0x80e4e4c in get_func_tv /home/pel/sb/vim/src/eval.c:8944 > > > > > #15 0x80d5ffb in eval7 /home/pel/sb/vim/src/eval.c:5282 > > > > > #16 0x80d4a82 in eval6 /home/pel/sb/vim/src/eval.c:4931 > > > > > #17 0x80d3e8d in eval5 /home/pel/sb/vim/src/eval.c:4747 > > > > > #18 0x80d28be in eval4 /home/pel/sb/vim/src/eval.c:4465 > > > > > #19 0x80d23e0 in eval3 /home/pel/sb/vim/src/eval.c:4382 > > > > > #20 0x80d1f4b in eval2 /home/pel/sb/vim/src/eval.c:4314 > > > > > #21 0x80d19b2 in eval1 /home/pel/sb/vim/src/eval.c:4242 > > > > > #22 0x80d177e in eval0 /home/pel/sb/vim/src/eval.c:4202 > > > > > #23 0x80c2a31 in eval_to_string /home/pel/sb/vim/src/eval.c:1447 > > > > > #24 0x80c2d27 in eval_to_string_safe > > > > > /home/pel/sb/vim/src/eval.c:1495 > > > > > #25 0x8065bda in build_stl_str_hl > > > > > /home/pel/sb/vim/src/buffer.c:3931 > > > > > #26 0x842433e in win_redr_custom > > > > > /home/pel/sb/vim/src/screen.c:7010 > > > > > #27 0x842315f in redraw_custom_statusline > > > > > /home/pel/sb/vim/src/screen.c:6792 > > > > > #28 0x8422225 in win_redr_status > > > > > /home/pel/sb/vim/src/screen.c:6663 > > > > > #29 0x8401360 in update_screen /home/pel/sb/vim/src/screen.c:708 > > > > > > > > > > previously allocated by thread T0 here: > > > > > #0 0xb721bf06 in malloc > > > > > (/usr/lib/i386-linux-gnu/libasan.so.2+0x96f06) > > > > > #1 0x82b7c31 in lalloc /home/pel/sb/vim/src/misc2.c:920 > > > > > #2 0x82b7ab5 in alloc /home/pel/sb/vim/src/misc2.c:818 > > > > > #3 0x82b7de3 in vim_strsave /home/pel/sb/vim/src/misc2.c:1253 > > > > > #4 0x812a454 in copy_tv /home/pel/sb/vim/src/eval.c:23374 > > > > > #5 0x81251ad in get_var_tv /home/pel/sb/vim/src/eval.c:22183 > > > > > #6 0x80d61ba in eval7 /home/pel/sb/vim/src/eval.c:5306 > > > > > #7 0x80d4a82 in eval6 /home/pel/sb/vim/src/eval.c:4931 > > > > > #8 0x80d3e8d in eval5 /home/pel/sb/vim/src/eval.c:4747 > > > > > #9 0x80d28be in eval4 /home/pel/sb/vim/src/eval.c:4465 > > > > > #10 0x80d23e0 in eval3 /home/pel/sb/vim/src/eval.c:4382 > > > > > #11 0x80d1f4b in eval2 /home/pel/sb/vim/src/eval.c:4314 > > > > > #12 0x80d19b2 in eval1 /home/pel/sb/vim/src/eval.c:4242 > > > > > #13 0x80d177e in eval0 /home/pel/sb/vim/src/eval.c:4202 > > > > > #14 0x80c246e in eval_to_bool /home/pel/sb/vim/src/eval.c:1369 > > > > > #15 0x81b5053 in ex_else /home/pel/sb/vim/src/ex_eval.c:1013 > > > > > #16 0x81821a2 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2921 > > > > > #17 0x817a626 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1107 > > > > > #18 0x8136248 in call_user_func /home/pel/sb/vim/src/eval.c:25475 > > > > > #19 0x80e5d43 in call_func /home/pel/sb/vim/src/eval.c:9158 > > > > > #20 0x80e4e4c in get_func_tv /home/pel/sb/vim/src/eval.c:8944 > > > > > #21 0x80d5ffb in eval7 /home/pel/sb/vim/src/eval.c:5282 > > > > > #22 0x80d4a82 in eval6 /home/pel/sb/vim/src/eval.c:4931 > > > > > #23 0x80d3e8d in eval5 /home/pel/sb/vim/src/eval.c:4747 > > > > > #24 0x80d28be in eval4 /home/pel/sb/vim/src/eval.c:4465 > > > > > #25 0x80d23e0 in eval3 /home/pel/sb/vim/src/eval.c:4382 > > > > > #26 0x80d1f4b in eval2 /home/pel/sb/vim/src/eval.c:4314 > > > > > #27 0x80d19b2 in eval1 /home/pel/sb/vim/src/eval.c:4242 > > > > > #28 0x80d177e in eval0 /home/pel/sb/vim/src/eval.c:4202 > > > > > #29 0x80c2a31 in eval_to_string /home/pel/sb/vim/src/eval.c:1447 > > > > > > > > > > SUMMARY: AddressSanitizer: heap-use-after-free > > > > > /home/pel/sb/vim/src/mbyte.c:1684 utf_ptr2char > > > > > Shadow bytes around the buggy address: > > > > > 0x3584c640: fa fa fd fa fa fa 03 fa fa fa fd fd fa fa fd fd > > > > > 0x3584c650: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fa > > > > > 0x3584c660: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fa > > > > > 0x3584c670: fa fa fd fa fa fa 06 fa fa fa fd fa fa fa 03 fa > > > > > 0x3584c680: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd > > > > > =>0x3584c690: fa fa fd fd fa fa[fd]fa fa fa fd fa fa fa fd fa > > > > > 0x3584c6a0: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fd > > > > > 0x3584c6b0: fa fa fd fd fa fa 03 fa fa fa fd fa fa fa fd fd > > > > > 0x3584c6c0: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fd > > > > > 0x3584c6d0: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa > > > > > 0x3584c6e0: fa fa fd fd fa fa fd fa fa fa fd fd fa fa 03 fa > > > > > Shadow byte legend (one shadow byte represents 8 application bytes): > > > > > Addressable: 00 > > > > > Partially addressable: 01 02 03 04 05 06 07 > > > > > Heap left redzone: fa > > > > > Heap right redzone: fb > > > > > Freed heap region: fd > > > > > Stack left redzone: f1 > > > > > Stack mid redzone: f2 > > > > > Stack right redzone: f3 > > > > > Stack partial redzone: f4 > > > > > Stack after return: f5 > > > > > Stack use after scope: f8 > > > > > Global redzone: f9 > > > > > Global init order: f6 > > > > > Poisoned by user: f7 > > > > > Container overflow: fc > > > > > Array cookie: ac > > > > > Intra object redzone: bb > > > > > ASan internal: fe > > > > > ==2354==ABORTING > > > > > > > > > > > > > > > I've also encountered another asan error (not sure yet if it's > > > > > caused by the same bug): > > > > > > > > > > ================================================================= > > > > > ==2811==ERROR: AddressSanitizer: heap-buffer-overflow on address > > > > > 0xb1742a94 at pc 0x0841b13b bp 0xbff74608 sp 0xbff745f8 > > > > > WRITE of size 1 at 0xb1742a94 thread T0 > > > > > #0 0x841b13a in win_line /home/pel/sb/vim/src/screen.c:5394 > > > > > #1 0x8401b40 in update_single_line > > > > > /home/pel/sb/vim/src/screen.c:824 > > > > > #2 0x85bce57 in main_loop /home/pel/sb/vim/src/main.c:1306 > > > > > #3 0x85bc4f6 in main /home/pel/sb/vim/src/main.c:1051 > > > > > #4 0xb63da73d in __libc_start_main > > > > > (/lib/i386-linux-gnu/libc.so.6+0x1873d) > > > > > #5 0x8052970 (/home/pel/sb/vim/src/vim+0x8052970) > > > > > > > > > > 0xb1742a94 is located 91 bytes to the right of 2489-byte region > > > > > [0xb1742080,0xb1742a39) > > > > > allocated by thread T0 here: > > > > > #0 0xb7215f06 in malloc > > > > > (/usr/lib/i386-linux-gnu/libasan.so.2+0x96f06) > > > > > #1 0x82b7c31 in lalloc /home/pel/sb/vim/src/misc2.c:920 > > > > > #2 0x842d920 in screenalloc /home/pel/sb/vim/src/screen.c:8563 > > > > > #3 0x842fe3c in screenclear /home/pel/sb/vim/src/screen.c:8828 > > > > > #4 0x84fd7e1 in set_shellsize /home/pel/sb/vim/src/term.c:3030 > > > > > #5 0x84fd3ff in shell_resized /home/pel/sb/vim/src/term.c:2944 > > > > > #6 0x8557a0c in gui_resize_shell /home/pel/sb/vim/src/gui.c:1484 > > > > > #7 0x857cf3f in form_configure_event > > > > > /home/pel/sb/vim/src/gui_gtk_x11.c:4450 > > > > > #8 0xb6dab22a > > > > > (/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0+0x12222a) > > > > > > > > Thanks for digging this up. I guess that conceal is being used, and > > > > after resizing it uses invalid information. update_screen() has a check > > > > for that, perhaps it's also needed in update_single_line(). Try adding > > > > this to the start of it: > > > > > > > > /* Don't do anything if the screen structures are (not yet) valid. > > > > */ > > > > if (!screen_valid(TRUE)) > > > > return; > > > > > > > > I hope you can reproduce this problem without the change, and not with > > > > this change. > > > > > > > > > The directory $HOME/.vim/bundle (linked to dotvim/bundle) > > > > > contains many plugins, but I found that it's the indentline > > > > > plugin available at https://github.com/Yggdroot/indentLine > > > > > that is triggering this crash: > > > > > - using the indentline plugin alone in $HOME/.vim/bundle > > > > > is enough to cause crashes > > > > > - if I use all plugins except indentline, I cannot make it crash. > > > > > > > > Does it use conceal mode? > > > > > > The indentline plugin does indeed use conceal. (It uses this to draw > > > vertical lines as guides to correctly line up your code). > > > I have disabled this plugin now and can't reproduce the crash anymore. > > > I'll try to build Vim with the above line and see what this gives. > > > > > I changed update_single_line() in screen.c: > > > > diff --git a/src/screen.c b/src/screen.c > > index a72bffa..2e425cb 100644 > > --- a/src/screen.c > > +++ b/src/screen.c > > @@ -801,6 +801,10 @@ update_single_line(win_T *wp, linenr_T lnum) > > int row; > > int j; > > > > + /* Don't do anything if the screen structures are (not yet) valid. */ > > + if (!screen_valid(TRUE)) > > + return; > > + > > if (lnum >= wp->w_topline && lnum < wp->w_botline > > && foldedCount(wp, lnum, &win_foldinfo) == 0) > > { > > > > Then I recompiled Vim (7.4.1825) and reenabled the indentline plugin, > > but this doesn't seem to fix the problem as Gvim crashes again when > > resizing a few times. If I run my compiled version without the > > indentlines plugin it doesn't crash. > > Thanks for trying. Looks like this requires debugging or adding some > log statements to find out what exactly is going wrong with the resizing > and conceal mode. I still suspect that conceal is redrawing when it > should not (cached information is wrong), but that "if" statement is not > sufficient. > > Debugging might be tricky, there probably is some race condition.
If I can try something additional to help find the cause of this issue I'm happy to help. Sadly I'm not familiar with the Vim source code or know enough of C to further dig into this issue on my own. Luckily I have had no further crashes for the past week since I disabled the indentline plugin. Jeroen -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
