Bram Moolenaar wrote:
> 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.
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.
...
=========================================
Anyway, preventing recursive redraws sounds like a sensible
thing to do. So far, I don't see any bad side effect.
-- Dominique
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
