gvim crash when switch to other tabs if NERDTree is opened
驼峰
I run into the following gvim crash happened when I try to switch to other tabs by using "1gt" or "2gt" if NERDTree is opened.
the crash is:
ChildEBP RetAddr
003bf2e8 776af5c9 ntdll!RtlReportCriticalFailure+0x29
003bf2f8 776af6a9 ntdll!RtlpReportHeapFailure+0x21
003bf32c 7766a5cb ntdll!RtlpLogHeapFailure+0xa1
003bf374 776135a7 ntdll!RtlpCoalesceFreeBlocks+0x84c
003bf46c 77613492 ntdll!RtlpFreeHeap+0x1f4
003bf48c 62c2a25d ntdll!RtlFreeHeap+0x142
003bf4b0 75e414dd AcXtrnal!NS_FaultTolerantHeap::APIHook_RtlFreeHeap+0x3e5
003bf4c4 01121879 kernel32!HeapFree+0x14
003bf4d8 010bb385 gvim!free+0x1c [f:\dd\vctools\crt_bld\self_x86\crt\src\free.c @ 51]
003bf4e4 010bd09e gvim!free_screenlines+0xc [k:\mercurial\vimcode\vim\src\screen.c @ 8210]
003bf540 010bd1c6 gvim!screenalloc+0x5e2 [k:\mercurial\vimcode\vim\src\screen.c @ 8138]
003bf54c 010eae28 gvim!screenclear+0xe [k:\mercurial\vimcode\vim\src\screen.c @ 8227]
003bf55c 010ebf1d gvim!set_shellsize+0xb7 [k:\mercurial\vimcode\vim\src\term.c @ 3068]
003bf56c 010fa2b9 gvim!shell_resized+0xa [k:\mercurial\vimcode\vim\src\term.c @ 2985]
003bf578 011006ba gvim!gui_resize_shell+0xc0 [k:\mercurial\vimcode\vim\src\gui.c @ 1456]
003bf5a4 010f9ad6 gvim!gui_mch_newfont+0x5b [k:\mercurial\vimcode\vim\src\gui_w48.c @ 3195]
003bf5cc 010fa926 gvim!gui_set_shellsize+0x30 [k:\mercurial\vimcode\vim\src\gui.c @ 1540]
003bf5f8 010fabdb gvim!gui_init_which_components+0x287 [k:\mercurial\vimcode\vim\src\gui.c @ 3488]
003bf600 010f4cf9 gvim!gui_may_update_scrollbars+0x1e [k:\mercurial\vimcode\vim\src\gui.c @ 4043]
003bf618 010f4d4c gvim!enter_tabpage+0xe6 [k:\mercurial\vimcode\vim\src\window.c @ 3715]
003bf624 010f5c59 gvim!goto_tabpage_tp+0x47 [k:\mercurial\vimcode\vim\src\window.c @ 3812]
003bf62c 01097548 gvim!goto_tabpage+0xad [k:\mercurial\vimcode\vim\src\window.c @ 3788]
003bf654 010944f1 gvim!nv_g_cmd+0x88b [k:\mercurial\vimcode\vim\src\normal.c @ 8364]
003bf6c4 0106ae0f gvim!normal_cmd+0x9f4 [k:\mercurial\vimcode\vim\src\normal.c @ 1201]
003bf754 0106ea8a gvim!main_loop+0x3ba [k:\mercurial\vimcode\vim\src\main.c @ 1282]
003bf838 0110348c gvim!VimMain+0x938 [k:\mercurial\vimcode\vim\src\main.c @ 986]
003bf968 01125777 gvim!WinMain+0x94 [k:\mercurial\vimcode\vim\src\os_w32exe.c @ 131]
003bf9f8 75e4339a gvim!__tmainCRTStartup+0x11a [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 275]
003bfa04 77619ef2 kernel32!BaseThreadInitThunk+0xe
003bfa44 77619ec5 ntdll!__RtlUserThreadStart+0x70
003bfa5c 00000000 ntdll!_RtlUserThreadStart+0x1b
I attached the crash analysis in attached file. I used the latest patch (470).
Does anyone have any clues?
Thanks,
-Mike
驼峰
Opened log file 'd:\gvimcrash.txt'
0:000> k
0:000> kP
ChildEBP RetAddr
003bf2e8 776af5c9 ntdll!RtlReportCriticalFailure+0x29
003bf2f8 776af6a9 ntdll!RtlpReportHeapFailure+0x21
003bf32c 7766a5cb ntdll!RtlpLogHeapFailure+0xa1
003bf374 776135a7 ntdll!RtlpCoalesceFreeBlocks+0x84c
003bf46c 77613492 ntdll!RtlpFreeHeap+0x1f4
003bf48c 62c2a25d ntdll!RtlFreeHeap+0x142
003bf4b0 75e414dd AcXtrnal!NS_FaultTolerantHeap::APIHook_RtlFreeHeap+0x3e5
003bf4c4 01121879 kernel32!HeapFree+0x14
003bf4d8 010bb385 gvim!free(
void * pBlock = 0x05cbc2c0)+0x1c [f:\dd\vctools\crt_bld\self_x86\crt\src\free.c @ 51]
003bf4e4 010bd09e gvim!free_screenlines(void)+0xc [k:\mercurial\vimcode\vim\src\screen.c @ 8210]
003bf540 010bd1c6 gvim!screenalloc(
int doclear = 0n0)+0x5e2 [k:\mercurial\vimcode\vim\src\screen.c @ 8138]
003bf54c 010eae28 gvim!screenclear(void)+0xe [k:\mercurial\vimcode\vim\src\screen.c @ 8227]
003bf55c 010ebf1d gvim!set_shellsize(
int width = 0n0,
int height = 0n0,
int mustset = 0n0)+0xb7 [k:\mercurial\vimcode\vim\src\term.c @ 3068]
003bf56c 010fa2b9 gvim!shell_resized(void)+0xa [k:\mercurial\vimcode\vim\src\term.c @ 2985]
003bf578 011006ba gvim!gui_resize_shell(
int pixel_width = 0n1920,
int pixel_height = 0n1118)+0xc0 [k:\mercurial\vimcode\vim\src\gui.c @ 1456]
003bf5a4 010f9ad6 gvim!gui_mch_newfont(void)+0x5b [k:\mercurial\vimcode\vim\src\gui_w48.c @ 3195]
003bf5cc 010fa926 gvim!gui_set_shellsize(
int mustset = 0n0,
int fit_to_display = 0n0,
int direction = 0n2)+0x30 [k:\mercurial\vimcode\vim\src\gui.c @ 1540]
003bf5f8 010fabdb gvim!gui_init_which_components(
unsigned char * oldval = 0x00000002 "--- memory read error at address 0x00000002 ---")+0x287 [k:\mercurial\vimcode\vim\src\gui.c @ 3488]
003bf600 010f4cf9 gvim!gui_may_update_scrollbars(void)+0x1e [k:\mercurial\vimcode\vim\src\gui.c @ 4043]
003bf618 010f4d4c gvim!enter_tabpage(
struct tabpage_S * tp = 0x00000000,
struct file_buffer * old_curbuf = 0x05e1dc98)+0xe6 [k:\mercurial\vimcode\vim\src\window.c @ 3715]
003bf624 010f5c59 gvim!goto_tabpage_tp(
struct tabpage_S * tp = 0x003fbc48)+0x47 [k:\mercurial\vimcode\vim\src\window.c @ 3812]
003bf62c 01097548 gvim!goto_tabpage(
int n = 0n1)+0xad [k:\mercurial\vimcode\vim\src\window.c @ 3788]
003bf654 010944f1 gvim!nv_g_cmd(
struct cmdarg_S * cap = 0x003bf66c)+0x88b [k:\mercurial\vimcode\vim\src\normal.c @ 8364]
003bf6c4 0106ae0f gvim!normal_cmd(
struct oparg_S * oap = 0x003bf6f0,
int toplevel = 0n1)+0x9f4 [k:\mercurial\vimcode\vim\src\normal.c @ 1201]
003bf754 0106ea8a gvim!main_loop(
int cmdwin = 0n0,
int noexmode = 0n0)+0x3ba [k:\mercurial\vimcode\vim\src\main.c @ 1282]
003bf838 0110348c gvim!VimMain(void)+0x938 [k:\mercurial\vimcode\vim\src\main.c @ 986]
003bf968 01125777 gvim!WinMain(
struct HINSTANCE__ * hInstance = 0x01010000,
struct HINSTANCE__ * hPrevInst = 0x00000000,
char * lpszCmdLine = 0x00743cc4 "-p --remote-tab-silent "" """,
int nCmdShow = 0n1)+0x94 [k:\mercurial\vimcode\vim\src\os_w32exe.c @ 131]
003bf9f8 75e4339a gvim!__tmainCRTStartup(void)+0x11a [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 275]
003bfa04 77619ef2 kernel32!BaseThreadInitThunk+0xe
003bfa44 77619ec5 ntdll!__RtlUserThreadStart+0x70
003bfa5c 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
Debugger WatsonDb Connection::Open failed 80040e4d
FAULTING_IP:
ntdll!RtlReportCriticalFailure+29
776ae695 cc int 3
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
.exr 0xffffffffffffffff
ExceptionAddress: 776ae695 (ntdll!RtlReportCriticalFailure+0x00000029)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 00000000
FAULTING_THREAD: 0000174c
PROCESS_NAME: gvim.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
EXCEPTION_PARAMETER1: 00000000
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Heap_Error_Type] from Frame:[0] on thread:[PSEUDO_THREAD] ; Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]
LAST_CONTROL_TRANSFER: from 776af5c9 to 776ae695
BUGCHECK_STR: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_entry_corruption_LOADER_INIT_FAILURE_c0000034_LOADER_INIT_FAILURE_c0000034
PRIMARY_PROBLEM_CLASS: ACTIONABLE_HEAP_CORRUPTION_heap_failure_entry_corruption
DEFAULT_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_entry_corruption
STACK_TEXT:
00000000 00000000 gvim!gui_set_shellsize+0x0
FOLLOWUP_IP:
gvim!gui_set_shellsize+0 [k:\mercurial\vimcode\vim\src\gui.c @ 1516]
010f9aa6 55 push ebp
FAULTING_SOURCE_CODE:
No source found for 'k:\mercurial\vimcode\vim\src\gui.c'
FAULTING_SOURCE_LINE: k:\mercurial\vimcode\vim\src\gui.c
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: gvim!gui_set_shellsize+0
FOLLOWUP_NAME: wintriag
MODULE_NAME: gvim
IMAGE_NAME: gvim.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4f582a6f
STACK_COMMAND: !heap ; dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ** Pseudo Context ** ; kb
FAILURE_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_entry_corruption_80000003_gvim.exe!gui_set_shellsize
BUCKET_ID: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_entry_corruption_LOADER_INIT_FAILURE_c0000034_LOADER_INIT_FAILURE_c0000034_gvim!gui_set_shellsize+0
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/gvim_exe/7_3_277_0/4f582a6f/ntdll_dll/6_1_7601_17725/4ec49b8f/80000003/000ce695.htm?Retriage=1
Followup: wintriag
---------
0:000> .logclose
Closing open log file d:\gvimcrash.txt
Bram Moolenaar
Guotuofeng wrote:
> The full crash analyze is:
>
> Opened log file 'd:\gvimcrash.txt'
> 0:000> k
> ChildEBP RetAddr
> 003bf2e8 776af5c9 ntdll!RtlReportCriticalFailure+0x29
> 003bf2f8 776af6a9 ntdll!RtlpReportHeapFailure+0x21
> 003bf32c 7766a5cb ntdll!RtlpLogHeapFailure+0xa1
> 003bf374 776135a7 ntdll!RtlpCoalesceFreeBlocks+0x84c
> 003bf46c 77613492 ntdll!RtlpFreeHeap+0x1f4
> 003bf48c 62c2a25d ntdll!RtlFreeHeap+0x142
> 003bf4b0 75e414dd AcXtrnal!NS_FaultTolerantHeap::APIHook_RtlFreeHeap+0x3e5
> 003bf4c4 01121879 kernel32!HeapFree+0x14
> 003bf4d8 010bb385 gvim!free+0x1c [f:\dd\vctools\crt_bld\self_x86\crt\src\free.c @ 51]
> 003bf4e4 010bd09e gvim!free_screenlines+0xc [k:\mercurial\vimcode\vim\src\screen.c @ 8210]
> 003bf540 010bd1c6 gvim!screenalloc+0x5e2 [k:\mercurial\vimcode\vim\src\screen.c @ 8138]
Don't see something special here.
Can you run Vim with valgrind, then we can see what happens with
allocated memory early. See ":help valgrind".
--
If you feel lonely, try schizophrenia.
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
驼峰
Thanks for your reply. Actually, I am working in Windows and don't
have valgrind.
The crash can be easily reproed by using two plugins: NERDTree and
buf_it.
Their links are:
http://www.vim.org/scripts/script.php?script_id=1658
http://www.vim.org/scripts/script.php?script_id=2833
The repro step is:
1. open a nerdtree window by using NERDTree.
2. in the NERDTree window, hit "t" key to create several tabs.
3. switch to other tabs by using "2gt" or click the tab button.
Then you will hit crash definitely.
After some investigation, I found the crash is hit by the command
"redraw" in buf_it.vim. If i comment out the redraw in that file. gvim
won't crash.
Here are some clauses related to redraw.
autocmd VimEnter,BufNew,BufEnter,BufWritePost,VimResized * call
UpdateStatus()
function! UpdateStatus()
blablabla
blablabla
blablabla
...
...
redraw
endfunction
Another easy repro step is adding the following line in vimrc
configuration file and install NERDTree.
autocmd VimEnter,BufNew,BufEnter,BufWritePost,VimResized *
redraw
Thanks,
-Mike Guo
>
> Don't see something special here.
>
> Can you run Vim with valgrind, then we can see what happens with
> allocated memory early. See ":help valgrind".
>
> --
> If you feel lonely, try schizophrenia.
>
> /// sponsor Vim, vote for features --http://www.Vim.org/sponsor/\\\
> \\\ an exciting new programming language --http://www.Zimbu.org ///
驼峰
pub/vim/pc/gvim73.zip), the problem still happens.
I guess that nobody hit this issue before. The scenario is: open
NERDTree windows and run redraw automatically when enter another tabs.
Thanks,
-Mike Guo
On Mar 9, 9:29 am, 驼峰 <guotuof...@gmail.com> wrote:
> Hi, Bram,
>
> Thanks for your reply. Actually, I am working in Windows and don't
> have valgrind.
>
> The crash can be easily reproed by using two plugins: NERDTree and
> buf_it.
>
lilydjwg
version 7.3.444.
> --
> 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
--
Best regards,
lilydjwg
Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?
驼峰
autocmd VimEnter,BufNew,BufEnter,BufWritePost,VimResized * redraw
The repro step:
1. open NERDTree
2. create multiple tabs.
3. switch tabs which contains NERDTree windows to other window.
4. If not crash, switch several times.
my environment: windows 7 amd64, my gvim is 32bits.
Thanks,
-Mike Guo
On Mar 9, 10:47 pm, lilydjwg <lilyd...@gmail.com> wrote:
> I can't reproduce this on my 32bit Windows XP with my self-compiled vim
> version 7.3.444.
>
>
>
>
>
>
>
>
>
> On Thu, Mar 08, 2012 at 05:44:01PM -0800, 驼峰 wrote:
> > BTW, I tried using the gvim 7.3 without any patches(ftp://ftp.vim.org/
> > pub/vim/pc/gvim73.zip), the problem still happens.
>
> > I guess that nobody hit this issue before. The scenario is: open
> > NERDTree windows and run redraw automatically when enter another tabs.
>
> > Thanks,
> > -Mike Guo
>
> > On Mar 9, 9:29 am, 驼峰 <guotuof...@gmail.com> wrote:
> > > Hi, Bram,
>
> > > Thanks for your reply. Actually, I am working in Windows and don't
> > > have valgrind.
>
> > > The crash can be easily reproed by using two plugins: NERDTree and
> > > buf_it.
>
Dominique Pellé
> I can 100% repro this bug by adding the following line into my vimrc.
>
> autocmd VimEnter,BufNew,BufEnter,BufWritePost,VimResized * redraw
>
> The repro step:
> 1. open NERDTree
> 2. create multiple tabs.
> 3. switch tabs which contains NERDTree windows to other window.
> 4. If not crash, switch several times.
>
> my environment: windows 7 amd64, my gvim is 32bits.
>
> Thanks,
> -Mike Guo
Hi
I can't reproduce it with vim-7.3.470 on Linux. No crash.
I also ran with Valgrind memory check and did not find problems.
Can you reproduce it by starting vim with "vim -u NONE"
and describing all the commands that result in a crash?
Regards
-- Dominique
驼峰
Christian J. Robinson
> I guess this only happens on Windows.
I cannot reproduce it on Windows 7 64bit with Vim 7.3.470.
- Christian
P.S. Stop top-posting your replies. It's confusing and against the
list's policy.
--
I owe, I owe, It's off to work I go...
Christian J. Robinson <hep...@gmail.com> http://christianrobinson.name/
驼峰
1: gvim 32 bits
2: only with NERDTree plugin
3: only with the following contents in my vimrc
autocmd VimEnter,BufNew,BufEnter,BufWritePost,VimResized * redraw
4: windows xp 32 bit.
my repro step:
1. run gvim
2. open NERDTree windows
3. create several tabs using 't' shortcut of NERDTree plugin
4. '1gt'
5, maximize gvim
6, '2gt'
7, restore the windows size from maximize window to normal window.
8, '1gt'
Result: after 8th step, my gvim will crash definitely.
Thanks,
-Mike Guo
驼峰
Christian J. Robinson
On Sat, 10 Mar 2012, 驼峰 wrote:
> my repro step:
> 1. run gvim
> 2. open NERDTree windows
> 3. create several tabs using 't' shortcut of NERDTree plugin
> 4. '1gt'
> 5, maximize gvim
> 6, '2gt'
> 7, restore the windows size from maximize window to normal window.
> 8, '1gt'
>
> Result: after 8th step, my gvim will crash definitely.
Yes, I can now crash gVim 7.3.470 on Windows 7 64bit using these
steps.
PLEASE stop top posting your replies!
- Christian
--
"I'm offended by political jokes. Too often they get elected."
-- Henny Youngman
Christian Brabandt
On Sa, 10 Mär 2012, 驼峰 wrote:
> my repro step:
> 1. run gvim
> 2. open NERDTree windows
> 3. create several tabs using 't' shortcut of NERDTree plugin
> 4. '1gt'
> 5, maximize gvim
> 6, '2gt'
> 7, restore the windows size from maximize window to normal window.
> 8, '1gt'
>
> Result: after 8th step, my gvim will crash definitely.
Bram, I think, this patch fixes it:
diff -r 94601b379f38 src/screen.c
--- a/src/screen.c Sun Mar 11 15:57:40 2012 +0100
+++ b/src/screen.c Tue Mar 13 00:05:34 2012 +0100
@@ -5371,6 +5371,9 @@
# define CHAR_CELLS 1
#endif
+ /* illegal screen size */
+ if (row > Rows)
+ row = Rows;
# ifdef FEAT_CLIPBOARD
clip_may_clear_selection(row, row);
# endif
@@ -5409,6 +5412,10 @@
}
#endif /* FEAT_RIGHTLEFT */
+ /* invalid screen access */
+ if (off_to > (unsigned) ((Rows) * Columns) || off_to < 0)
+ off_to = (unsigned) Rows * Columns;
+
redraw_next = char_needs_redraw(off_from, off_to, endcol - col);
while (col < endcol)
regards,
Christian
Sergey Khorev
> 1. run gvim
> 2. open NERDTree windows
> 3. create several tabs using 't' shortcut of NERDTree plugin
> 4. '1gt'
> 5, maximize gvim
> 6, '2gt'
> 7, restore the windows size from maximize window to normal window.
> 8, '1gt'
>
> Result: after 8th step, my gvim will crash definitely.
My take on this problem (apply autocommands only once window sizes
have been adjusted):
diff -r b3ccae22bae7 src/window.c
--- a/src/window.c Wed Mar 07 22:55:21 2012 +0100
+++ b/src/window.c Mon Mar 12 21:57:24 2012 +0400
@@ -3676,13 +3676,6 @@
win_enter_ext(tp->tp_curwin, FALSE, TRUE);
prevwin = next_prevwin;
-#ifdef FEAT_AUTOCMD
- apply_autocmds(EVENT_TABENTER, NULL, NULL, FALSE, curbuf);
-
- if (old_curbuf != curbuf)
- apply_autocmds(EVENT_BUFENTER, NULL, NULL, FALSE, curbuf);
-#endif
-
last_status(FALSE); /* status line may appear or disappear */
(void)win_comp_pos(); /* recompute w_winrow for all windows */
must_redraw = CLEAR; /* need to redraw everything */
@@ -3712,6 +3705,13 @@
gui_may_update_scrollbars();
#endif
+#ifdef FEAT_AUTOCMD
+ apply_autocmds(EVENT_TABENTER, NULL, NULL, FALSE, curbuf);
+
+ if (old_curbuf != curbuf)
+ apply_autocmds(EVENT_BUFENTER, NULL, NULL, FALSE, curbuf);
+#endif
+
redraw_all_later(CLEAR);
}
Bram Moolenaar
Christian Brabandt write:
> On Sa, 10 Mär 2012, 驼峰 wrote:
>
> > my repro step:
> > 1. run gvim
> > 2. open NERDTree windows
> > 3. create several tabs using 't' shortcut of NERDTree plugin
> > 4. '1gt'
> > 5, maximize gvim
> > 6, '2gt'
> > 7, restore the windows size from maximize window to normal window.
> > 8, '1gt'
> >
> > Result: after 8th step, my gvim will crash definitely.
>
> Bram, I think, this patch fixes it:
Thanks for the patch. I have been unable to reproduce the crash, I hope
someone can verify this patch fixes the problem.
I do wonder how "row" can be too big, perhaps there is a problem at a
higher level? Or a sequence of events in the wrong order?
Ah, I see that Sergey has an alternative patch. Comments?
--
Wizards had always known that the act of observation changed the thing that
was observed, and sometimes forgot that it also changed the observer too.
Terry Pratchett - Interesting times
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
Sergey Khorev
> someone can verify this patch fixes the problem.
Have you added autocmd
VimEnter,BufNew,BufEnter,BufWritePost,VimResized * redraw? It is an
essential part.
> I do wonder how "row" can be too big, perhaps there is a problem at a
> higher level? Or a sequence of events in the wrong order?
When the main Vim windows is resized, only current tab is adjusted.
So, after step 7, windows on the first tab still think they are in the
full size tab. Forced redraw in the autocommand fires when windows are
not adjusted yet so Vim crashes in screen_line which receives out of
bound row number from win_line.
Christian Brabandt
>
> Christian Brabandt write:
>
>> On Sa, 10 Mär 2012, 驼峰 wrote:
>>
>> > my repro step:
>> > 1. run gvim
>> > 2. open NERDTree windows
>> > 3. create several tabs using 't' shortcut of NERDTree plugin
>> > 4. '1gt'
>> > 5, maximize gvim
>> > 6, '2gt'
>> > 7, restore the windows size from maximize window to normal window.
>> > 8, '1gt'
>> >
>> > Result: after 8th step, my gvim will crash definitely.
>>
>> Bram, I think, this patch fixes it:
>
> Thanks for the patch. I have been unable to reproduce the crash, I hope
> someone can verify this patch fixes the problem.
I could only reproduce it on Windows. On Linux with a gtk-built version,
I couldn't reproduce it either.
> I do wonder how "row" can be too big, perhaps there is a problem at a
> higher level? Or a sequence of events in the wrong order?
I think somehow, the LineOffset array has not been updated to reflect
the new screen size.
> Ah, I see that Sergey has an alternative patch. Comments?
Sergey probably has been using the right approach. My patch just prevents
access of invalid screen lines, which prevents the crash in this case
and probably doesn't hurt anyway.
regards,
Christian
驼峰
when can this bug be fixed? I am waiting the crash fix for several
days.
thanks,
mike
Christian Brabandt
Please don't top poste. This has been told you already several times.
See http://en.wikipedia.org/wiki/Posting_style for an explanation, what
this means.
On Fr, 16 Mär 2012, 驼峰 wrote:
> when can this bug be fixed? I am waiting the crash fix for several
> days.
This has just been fixed with patch 7.3.472.
regards,
Christian
--