Dominique Pelle wrote:

> Bram Moolenaar wrote:
> 
> > Bjorn Winckler wrote:
> >
> >> A MacVim user ran into a bug using :vimgrep as reported here:
> >>
> >> http://tinyurl.com/kqg2fm
> >>
> >> The bug has been reproduced with 7.2.234 but not in 7.2.148.  I can
> >> reproduce with the following steps:
> >>
> >> 1. open Vim, cd to root dir of Vim sources
> >> 2. :vimgrep FEAT_EVAL **/*
> >> 3. crash  (on occasion I had to type in a longer search term than
> >> FEAT_EVAL, underscores seem to matter by looking at the original
> >> report)
> >>
> >> I had a quick check with GDB and the problem is on line 8556 in
> >> fileio.c.  The curwin pointer is set to NULL.  It is set to NULL just
> >> before on line 8549 due to firstwin being NULL.  Haven't figured out
> >> why this happens and have run out of time now so I thought I'd report
> >> my findings.
> >>
> >> Backtrace:
> >>
> >> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> >> 0x000893cd in aucmd_restbuf (aco=0xbfffe458) at fileio.c:8556
> >> 8556          curbuf = curwin->w_buffer;
> >> (gdb) bt
> >> #0  0x000893cd in aucmd_restbuf (aco=0xbfffe458) at fileio.c:8556
> >> #1  0x0011cc10 in load_dummy_buffer (fname=0x502e40
> >> "farsi/fonts/UNIXs/far-a01.pcf.Z") at quickfix.c:3447
> >> #2  0x0011c390 in ex_vimgrep (eap=0xbfffef04) at quickfix.c:3146
> >> #3  0x0005eb9f in do_one_cmd (cmdlinep=0xbffff354, sourcing=0,
> >> cstack=0xbffff050, fgetline=0x753b1 <getexline>, cookie=0x0) at
> >> ex_docmd.c:2634
> >> #4  0x0005b8fd in do_cmdline (cmdline=0x0, getline=0x753b1
> >> <getexline>, cookie=0x0, flags=0) at ex_docmd.c:1103
> >> #5  0x000ec961 in nv_colon (cap=0xbffff478) at normal.c:5252
> >> #6  0x000e4d30 in normal_cmd (oap=0xbffff534, toplevel=1) at normal.c:1188
> >> #7  0x0009fc4f in main_loop (cmdwin=0, noexmode=0) at main.c:1261
> >> #8  0x0009f742 in main (argc=3, argv=0xbffff700) at main.c:1005
> >
> > Hopefully this is fixed by this pending patch:
> ...snip...
> 
> 
> That fixes the crash for me as well.  Thanks.
> 
> However, I saw the following memory leak using Vim-7.2.239, huge,
> with patch and built with -DEXITFREE:
> 
> ==32670== 544 bytes in 1 blocks are definitely lost in loss record 104 of 113
> ==32670==    at 0x402603E: malloc (vg_replace_malloc.c:207)
> ==32670==    by 0x81090B6: lalloc (misc2.c:866)
> ==32670==    by 0x8108FDC: alloc_clear (misc2.c:777)
> ==32670==    by 0x81B3EE0: win_alloc_lines (window.c:4512)
> ==32670==    by 0x81B3A93: win_alloc (window.c:4248)
> ==32670==    by 0x81B27A7: win_alloc_aucmd_win (window.c:3261)
> ==32670==    by 0x80C9832: aucmd_prepbuf (fileio.c:8419)
> ==32670==    by 0x814AAEF: load_dummy_buffer (quickfix.c:3430)
> ==32670==    by 0x814A2BE: ex_vimgrep (quickfix.c:3158)
> ==32670==    by 0x80A4174: do_one_cmd (ex_docmd.c:2627)
> ==32670==    by 0x80A1A1C: do_cmdline (ex_docmd.c:1096)
> ==32670==    by 0x811F12A: nv_colon (normal.c:5224)
> ==32670==    by 0x8118838: normal_cmd (normal.c:1188)
> ==32670==    by 0x80DFCFE: main_loop (main.c:1186)
> ==32670==    by 0x80DF84B: main (main.c:942)
> 
> I noticed it once after I applied the patch and followed the steps to
> try to reproduce the crash (:vimgrep FEAT_EVAL **/*). I also tried
> a couple of other commands before exiting, and then saw the leak.
> Unfortunately, I can't reproduce it so I'm not sure yet what triggered it.
> I'll add more information, if I can find how to reproduce it.

It may happen when resizing the Vim window.  This patch should fix it:


*** ../vim-7.2.239/src/screen.c 2009-06-16 17:22:38.000000000 +0200
--- src/screen.c        2009-07-26 12:50:46.000000000 +0200
***************
*** 7467,7472 ****
--- 7467,7476 ----
       */
      FOR_ALL_TAB_WINDOWS(tp, wp)
        win_free_lsize(wp);
+ #ifdef FEAT_AUTOCMD
+     if (aucmd_win != NULL)
+       win_free_lsize(aucmd_win);
+ #endif
  
      new_ScreenLines = (schar_T *)lalloc((long_u)(
                              (Rows + 1) * Columns * sizeof(schar_T)), FALSE);



-- 
Laughing helps. It's like jogging on the inside.

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Raspunde prin e-mail lui