Dominique Pelle wrote:
> >> I can reproduce a memory leak with Vim-7.2.293 (and older).
> >>
> >> Steps to reproduce:
> >>
> >> 1/ Create the following minimalistic script:
> >>
> >> Â $ cat leak.vim
> >>
> >> Â function Foo()
> >> Â Â redraw!
> >> Â Â return ''
> >> Â endfunction
> >>
> >> Â set hlsearch
> >> Â set laststatus=2
> >> Â set statusline=%{Foo()}
> >>
> >> 2/ Start Vim with Valgrind using:
> >>
> >> Â Â $ cd vim7/src
> >> Â Â $ valgrind --leak-check=yes ./vim \
> >> Â Â Â Â --noplugin \
> >> Â Â Â Â -u leak.vim buffer.c \
> >> Â Â Â Â -c 'exe "normal /to\<CR>"' 2> vg.log
> >>
> >> 3/ Press  n  several times (press 3 times for example) to go to next
> >> Â Â match several times.
> >>
> >> 4/ Quit Vim with:
> >>
> >> Â Â :q!
> >>
> >> 5/ Observe in vg.log the following memory leaks:
> >>
> >> ==15737== 164 bytes in 4 blocks are definitely lost in loss record 100 of
> >> 113
> >> ==15737== Â Â at 0x402603E: malloc (vg_replace_malloc.c:207)
> >> ==15737== Â Â by 0x8115C72: lalloc (misc2.c:866)
> >> ==15737== Â Â by 0x815AAF7: vim_regcomp (regexp.c:1021)
> >> ==15737== Â Â by 0x81747EA: search_regcomp (search.c:216)
> >> ==15737== Â Â by 0x817505C: last_pat_prog (search.c:501)
> >> ==15737== Â Â by 0x816F71E: start_search_hl (screen.c:6590)
> >> ==15737== Â Â by 0x816488C: update_screen (screen.c:505)
> >> ==15737== Â Â by 0x80E7C97: main_loop (main.c:1121)
> >> ==15737== Â Â by 0x80E792D: main (main.c:948)
> >>
> >> One block is leaked when doing the first search with  /to  then
> >> other blocks are leaked every time you press  n  to go to next
> >> match.  In above example I pressed  n  3 times so there was 1+3=4
> >> leaks in total.
> >>
> >> Attached patch fixes it.
> >
> > The root cause appears to be calling screen_update() recursively. Â Your
> > patch depends on the runtime to clear static memory. Â That is not
> > guaranteed to happen.
> >
> > Please try out the patch below. Â It's a drastic change to disallow
> > recursive screen updates. Â I can't be sure this is without side effects,
> > but I do think we don't want screen_update() to be used recursively.
>
> ...snip...
>
> Thanks. I verified that your patch fixes the memory leak.
Thanks for testing.
> I assumed that variables in .bss (search_hl in this case) are always
> initialized to 0. Out of curiousity, on which version of Vim that is not
> the case?
>
> =========================================
> $ man elf
> ...
> Various sections hold program and control information:
>
> .bss This section holds uninitialized data that contributes to the
> program’s memory image. By definition, the system initialâ€
> izes the data with zeros when the program begins to run.
> This section is of type SHT_NOBITS. The attribute types are
> SHF_ALLOC and SHF_WRITE.
> ...
> =========================================
On modern systems this should happen. But there are a few systems where
this does not happen.
> Anyway, preventing recursive redraws sounds like a sensible
> thing to do. So far, I don't see any bad side effect.
I'll wait a bit longer.
--
It is too bad that the speed of light hasn't kept pace with the
changes in CPU speed and network bandwidth. -- <[email protected]>
/// 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
-~----------~----~----~----~------~----~------~--~---
