Loading ...
Sorry, an error occurred while loading the content.

Re: Crash during :vimgrep in 7.2.234

Expand Messages
  • Bram Moolenaar
    ... It may happen when resizing the Vim window. This patch should fix it: ... *************** ... */ FOR_ALL_TAB_WINDOWS(tp, wp) win_free_lsize(wp); + #ifdef
    Message 1 of 7 , Jul 26, 2009
    • 0 Attachment
      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 -- Bram@... -- 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
      -~----------~----~----~----~------~----~------~--~---
    Your message has been successfully submitted and would be delivered to recipients shortly.