Re: Memory leak reported by valgrind in set_init_1()
Yegappan wrote: > Running the latest Vim under valgrind reports the following memory leak: > > ==608== 2 bytes in 2 blocks are definitely lost in loss record 2 of 27 > ==608==at 0x4A06A2E: malloc (vg_replace_malloc.c:270) > ==608==by 0x4F2DAA: lalloc (misc2.c:976) > ==608==by 0x4F2C76: alloc (misc2.c:874) > ==608==by 0x4F3253: vim_strsave (misc2.c:1315) > ==608==by 0x5297FC: set_string_option_direct (option.c:5926) > ==608==by 0x525640: set_option_default (option.c:3811) > ==608==by 0x5258E6: set_options_default (option.c:3887) > ==608==by 0x525178: set_init_1 (option.c:3567) > ==608==by 0x6438EE: common_init (main.c:1030) > ==608==by 0x642B13: main (main.c:180) > ==608== > > To reproduce this, start Vim under valgrind and then exit Vim. This is because 'termkey' and 'termsize' are currently duplicated, while we are switching over to 'termwinkey' and 'termwinsize'. I'll add some code to avoid it. -- Edison's greatest achievement came in 1879, when he invented the electric company. Edison's design was a brilliant adaptation of the simple electrical circuit: the electric company sends electricity through a wire to a customer, then immediately gets the electricity back through another wire /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Memory leak in find_some_match()
Yegappan Lakshmanan wrote: > Running the test_matchstrpos.vim test under valgrind reports a > small memory leak in the find_some_match() function. The attached > patch fixes this leak. Thanks! -- Due knot trussed yore spell chequer two fined awl miss steaks. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Memory leak in ex_vimgrep()
Yegappan Lakshmanan wrote: > Valgrind detected a memory leak in the ex_vimgrep() function when running > the Test_nomem() function in the test_quickfix.vim file. The attached patch > fixes this leak. Thanks. Glad to see that adding this kind of test can locate problems. -- Normal people believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Memory leak
Dimitar wrote: 1. valgrind --leak-check=full --show-reachable=yes ./vim -u NONE -U NONE 2. ZQ ==14191== LEAK SUMMARY: ==14191==definitely lost: 36 bytes in 1 blocks. ==14191==indirectly lost: 120 bytes in 10 blocks. ==14191== possibly lost: 0 bytes in 0 blocks. ==14191==still reachable: 40,689 bytes in 261 blocks. ==14191== suppressed: 0 bytes in 0 blocks. VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Jul 13 2010 20:27:14) Included patches: 1-446 [...] Please check where the leaks are. At least some of them will be in libraries. Those can't be avoided. And you need to compile Vim with EXITFREE defined, otherwise it won't clean up. -- A real patriot is the fellow who gets a parking ticket and rejoices that the system works. /// Bram Moolenaar -- b...@moolenaar.net -- 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Memory leak
On 09/07/10 00:26, Dimitar DIMITROV wrote:
valgrind --leak-check=full --show-reachable=yes gvim
1. cc, then a,a,a,a,a,a,a,a,a,a,a,
2. /\(\(\s*\w\+\s*\)\+,\)\{1,20}
3. :h\{
4. Close gvim
==3987== LEAK SUMMARY:
==3987== definitely lost: 12,986 bytes in 47 blocks.
==3987== indirectly lost: 28,332 bytes in 1,403 blocks.
==3987== possibly lost: 349,216 bytes in 498 blocks.
==3987== still reachable: 3,245,978 bytes in 47,532 blocks.
==3987== suppressed: 0 bytes in 0 blocks.
VIM - Vi IMproved 7.1 (2007 May 12, compiled Oct 17 2008 18:04:59)
Included patches: 1-314
[...]
On 09/07/10 00:29, Dimitar DIMITROV wrote:
1. f1
2. 3yy`]
3. 5yy`]
==4008== LEAK SUMMARY:
==4008== definitely lost: 37,350 bytes in 116 blocks.
==4008== indirectly lost: 28,332 bytes in 1,403 blocks.
==4008== possibly lost: 319,554 bytes in 469 blocks.
==4008== still reachable: 2,425,077 bytes in 30,351 blocks.
==4008== suppressed: 0 bytes in 0 blocks.
VIM - Vi IMproved 7.1 (2007 May 12, compiled Oct 17 2008 18:04:59)
Included patches: 1-314
[...]
7.1, even 7.1.314, is not the latest version. Among the 445 patches
already published for the _next_ version (7.2), more than a few were
leak fixes, see http://ftp.vim.org/pub/vim/patches/7.2/README
If you want to usefully contribute memory leak reports, please use the
latest version, either the latest stable version (currently 7.2.445) or
the bleeding-edge development version (7.3a, available only over
Mercurial, not as a bz2 archive).
See:
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial (7.2 or
7.3a)
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm (compiling)
On Debian, you should be able to use apt-get to get the dependencies
of the vim-x11 package (or of whatever it is called on that distro).
Best regards,
Tony.
--
For every credibility gap, there is a gullibility fill.
-- R. Clopton
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Memory leak
On Thu, Jul 8, 2010 at 6:55 PM, Tony Mechelynck wrote: If you want to usefully contribute memory leak reports, please use the latest version, either the latest stable version (currently 7.2.445) or the bleeding-edge development version (7.3a, available only over Mercurial, not as a bz2 archive). ... On Debian, you should be able to use apt-get to get the dependencies of the vim-x11 package (or of whatever it is called on that distro). Indeed. apt-get build-dep vim-gnome ~Matt -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: memory leak in vim-7.1.135 when doing so %
On 10/7/07, Tony Mechelynck [EMAIL PROTECTED] wrote: It's not clear to me what memory is leaked (if any is really leaked, valgrind may give a false warning). When I put this line before syntax on it appears to disappear: let g:vimembedscript= 0 So it's related to :syn include. What this setting changes is that it forbids sourcing of syntax/perl.vim, syntax/python.vim, syntax/tcl.vim, syntax/ruby.vim and syntax/scheme.vim from within syntax/vim.vim so maybe you (Dominique) might want to investigate which one(s) of them leak(s) memory. (Rename one or more of them to something else, or move them elsewhere -- temporarily of course -- and see if the leak persists.) Best regards, Tony. I can confirm that I also don't see the leak anymore when I add let g:vimembedscript= 0 in the leak.vim script. Following the good advice of Tony, by trial and error, i.e. commenting pieces of /usr/local/share/vim/vim71/syntax/vim.vim, I found this: - comment out all of ruby python tcl mzscheme --- no leak - enable perl syntax only --- no leak - enable ruby syntax only --- ***LEAK!*** - enable python syntax only - no leak - enable tcl syntax only no leak - enable mzscheme syntax only --- no leak So the leak (assuming it's not spurious) comes somehow from ruby.vim only. I will try to narrow down further in ruby.vim later when I have time. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: memory leak in vim-7.1.135 when doing so %
Dominique Pelle wrote: vim seems to be leaking memory when doing :so % with syntax on setting. Steps to reproduce: 1/ create a simple script as follows: $ cat leak.vim leaks memory when doing :so % while this file is loaded in vim syntax on 2/ start vim $ valgrind --leak-check=yes vim -u NONE -U NONE leak.vim 2 vg.log 3/ in vim, source the current buffer (leak.vim), then quit :so % :q 4/ observe that valgrind reports a memory leak ==18415== 22 bytes in 4 blocks are definitely lost in loss record 2 of 15 ==18415==at 0x4021620: malloc (vg_replace_malloc.c:149) ==18415==by 0x8102F4C: lalloc (misc2.c:857) ==18415==by 0x8102E6E: alloc (misc2.c:756) ==18415==by 0x818C3B1: get_id_list (syntax.c:5761) ==18415==by 0x81898E6: get_syn_options (syntax.c:4338) ==18415==by 0x818A5E6: syn_cmd_region (syntax.c:4785) ==18415==by 0x818C84A: ex_syntax (syntax.c:5974) ==18415==by 0x809B897: do_one_cmd (ex_docmd.c:2621) ==18415==by 0x80990FC: do_cmdline (ex_docmd.c:1099) ==18415==by 0x80973A1: do_source (ex_cmds2.c:3054) ==18415==by 0x8189DBF: syn_cmd_include (syntax.c:4494) ==18415==by 0x818C84A: ex_syntax (syntax.c:5974) Whenever Ex command :so % is run, with syntax on in script, 4 more blocks of memory leak, i.e.: - If I do :so % once, I see: 22 bytes in 4 blocks are definitely lost in loss record 2 of 15 - If I do :so % twice, I see: 44 bytes in 8 blocks are definitely lost in loss record 11 of 15 - I I do : so % three times, I see: 66 bytes in 12 blocks are definitely lost in loss record 10 of 15 - etc. I built vim-7.1.135 on Linux with: - configure --with-features=huge - changed src/Makefile to compile without optimisation (-O0) - changed src/Makefile to enable PROFILE_CFLAGS = -DEXITFREE I don't have a patch as I am unsure where it should be freed. It's not clear to me what memory is leaked (if any is really leaked, valgrind may give a false warning). When I put this line before syntax on it appears to disappear: let g:vimembedscript= 0 So it's related to :syn include. -- Engineers are always delighted to share wisdom, even in areas in which they have no experience whatsoever. Their logic provides them with inherent insight into any field of expertise. This can be a problem when dealing with the illogical people who believe that knowledge can only be derived through experience. (Scott Adams - The Dilbert principle) /// 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 -~--~~~~--~~--~--~---
Re: memory leak in vim-7.1.135 when doing so %
Bram Moolenaar wrote: Dominique Pelle wrote: vim seems to be leaking memory when doing :so % with syntax on setting. Steps to reproduce: 1/ create a simple script as follows: $ cat leak.vim leaks memory when doing :so % while this file is loaded in vim syntax on 2/ start vim $ valgrind --leak-check=yes vim -u NONE -U NONE leak.vim 2 vg.log 3/ in vim, source the current buffer (leak.vim), then quit :so % :q 4/ observe that valgrind reports a memory leak ==18415== 22 bytes in 4 blocks are definitely lost in loss record 2 of 15 ==18415==at 0x4021620: malloc (vg_replace_malloc.c:149) ==18415==by 0x8102F4C: lalloc (misc2.c:857) ==18415==by 0x8102E6E: alloc (misc2.c:756) ==18415==by 0x818C3B1: get_id_list (syntax.c:5761) ==18415==by 0x81898E6: get_syn_options (syntax.c:4338) ==18415==by 0x818A5E6: syn_cmd_region (syntax.c:4785) ==18415==by 0x818C84A: ex_syntax (syntax.c:5974) ==18415==by 0x809B897: do_one_cmd (ex_docmd.c:2621) ==18415==by 0x80990FC: do_cmdline (ex_docmd.c:1099) ==18415==by 0x80973A1: do_source (ex_cmds2.c:3054) ==18415==by 0x8189DBF: syn_cmd_include (syntax.c:4494) ==18415==by 0x818C84A: ex_syntax (syntax.c:5974) Whenever Ex command :so % is run, with syntax on in script, 4 more blocks of memory leak, i.e.: - If I do :so % once, I see: 22 bytes in 4 blocks are definitely lost in loss record 2 of 15 - If I do :so % twice, I see: 44 bytes in 8 blocks are definitely lost in loss record 11 of 15 - I I do : so % three times, I see: 66 bytes in 12 blocks are definitely lost in loss record 10 of 15 - etc. I built vim-7.1.135 on Linux with: - configure --with-features=huge - changed src/Makefile to compile without optimisation (-O0) - changed src/Makefile to enable PROFILE_CFLAGS = -DEXITFREE I don't have a patch as I am unsure where it should be freed. It's not clear to me what memory is leaked (if any is really leaked, valgrind may give a false warning). When I put this line before syntax on it appears to disappear: let g:vimembedscript= 0 So it's related to :syn include. What this setting changes is that it forbids sourcing of syntax/perl.vim, syntax/python.vim, syntax/tcl.vim, syntax/ruby.vim and syntax/scheme.vim from within syntax/vim.vim so maybe you (Dominique) might want to investigate which one(s) of them leak(s) memory. (Rename one or more of them to something else, or move them elsewhere -- temporarily of course -- and see if the leak persists.) Best regards, Tony. -- God may be subtle, but He isn't plain mean. -- Albert Einstein --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
