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. Thanks -- Dominique --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
