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?
> I have not come with a fix yet, but hopefully
> the information here can help, if someone else
> wants to debug it too.
--
Mynd you, m00se bites Kan be pretty nasti ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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.
