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. -- It might look like I'm doing nothing, but at the cellular level I'm really quite busy. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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.
