Dominique Pellé <[email protected]> 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)
SUMMARY: AddressSanitizer: heap-buffer-overflow
/home/pel/sb/vim/src/screen.c:5394 win_line
Shadow bytes around the buggy address:
0x362e8500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x362e8510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x362e8520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x362e8530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x362e8540: 00 00 00 00 00 00 00 01 fa fa fa fa fa fa fa fa
=>0x362e8550: fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa
0x362e8560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x362e8570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x362e8580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x362e8590: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x362e85a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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
==2811==ABORTING
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.
I have not come with a fix yet, but hopefully
the information here can help, if someone else
wants to debug it too.
Regards
Dominique
--
--
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.
