Commit: patch 9.1.0189: Memory leak with "above" virttext and 'relativenumber'
patch 9.1.0189: Memory leak with "above" virttext and 'relativenumber'
Commit:
https://github.com/vim/vim/commit/918b92b961ac319ddb5f24d8cade2cf6aeebc5d5
Author: zeertzjq
Date: Wed Mar 20 19:49:20 2024 +0100
patch 9.1.0189: Memory leak with "above" virttext and 'relativenumber'
Problem: Memory leak with "above" virtual text and 'relativenumber'.
Solution: Free "text_props" and "text_prop_idxs" before returning.
Also fix off-by-one error causing line number to be drawn
beyond end of window (zeertzjq).
fixes: #14239
closes: #14241
Signed-off-by: zeertzjq
Signed-off-by: Christian Brabandt
diff --git a/src/drawline.c b/src/drawline.c
index ed02f3cab..a8de449af 100644
--- a/src/drawline.c
+++ b/src/drawline.c
@@ -1683,8 +1683,12 @@ win_line(
{
// skip over rows only used for virtual text above
wlv.row += wlv.text_prop_above_count;
- if (wlv.row > endrow)
+ if (wlv.row >= endrow)
+ {
+ vim_free(text_props);
+ vim_free(text_prop_idxs);
return wlv.row;
+ }
wlv.screen_row += wlv.text_prop_above_count;
}
#endif
diff --git a/src/testdir/dumps/Test_prop_above_below_empty_6.dump
b/src/testdir/dumps/Test_prop_above_below_empty_6.dump
new file mode 100644
index 0..501364371
--- /dev/null
+++ b/src/testdir/dumps/Test_prop_above_below_empty_6.dump
@@ -0,0 +1,16 @@
+| +0#af5f00255#ff0@3|-+0#001#4012| +0#000#ff0@54
+| +0#af5f00255&@1|1| |1+0#000&@7| @47
+| +0#af5f00255&@3|++0#001#4012| +0#000#ff0@54
+| +0#af5f00255&@3|-+0#001#4012| +0#000#ff0@54
+|2+0#af5f00255&| @2> +0#000&@55
+| +0#af5f00255&@3|++0#001#4012| +0#000#ff0@54
+| +0#af5f00255&@3|-+0#001#4012| +0#000#ff0@54
+| +0#af5f00255&@1|1| |3+0#000&@8| @46
+| +0#af5f00255&@3|++0#001#4012| +0#000#ff0@54
+| +0#af5f00255&@3|-+0#001#4012| +0#000#ff0@54
+| +0#af5f00255&@1|2| | +0#000&@55
+| +0#af5f00255&@3|++0#001#4012| +0#000#ff0@54
+| +0#af5f00255&@3|-+0#001#4012| +0#000#ff0@54
+| +0#af5f00255&@3|!+0#001#4012| +0#000#ff0@54
+|@+0#4040ff13&@2| @56
+|:+0#000&|c|a|l@1| |A|d@1|M|o|r|e|(|)| @26|2|,|0|-|5|7| @7|T|o|p|
diff --git a/src/testdir/test_textprop.vim b/src/testdir/test_textprop.vim
index c88b5477a..a06f73370 100644
--- a/src/testdir/test_textprop.vim
+++ b/src/testdir/test_textprop.vim
@@ -3080,6 +3080,12 @@ func Test_prop_with_text_above_below_empty()
call prop_add(ln, 0, {'type': vt, 'text': '+', 'text_align': 'below'})
endfor
normal G
+
+ func AddMore()
+call prop_add(5, 0, {'type': g:vt, 'text': '!', 'text_align': 'above'})
+call prop_add(5, 0, {'type': g:vt, 'text': '!', 'text_align': 'above'})
+call prop_add(5, 0, {'type': g:vt, 'text': '!', 'text_align': 'above'})
+ endfunc
END
call writefile(lines, 'XscriptPropAboveBelowEmpty', 'D')
let buf = RunVimInTerminal('-S XscriptPropAboveBelowEmpty', #{rows: 16,
cols: 60})
@@ -3101,6 +3107,12 @@ func Test_prop_with_text_above_below_empty()
call term_sendkeys(buf, "kk")
call VerifyScreenDump(buf, 'Test_prop_above_below_empty_5', {})
+ " This was drawing line number over cmdline and leaking memory.
+ call term_sendkeys(buf, ":call AddMore()\")
+ call term_sendkeys(buf, "gg")
+ call term_sendkeys(buf, "j")
+ call VerifyScreenDump(buf, 'Test_prop_above_below_empty_6', {})
+
call StopVimInTerminal(buf)
endfunc
diff --git a/src/version.c b/src/version.c
index db093a7e4..3affeffad 100644
--- a/src/version.c
+++ b/src/version.c
@@ -704,6 +704,8 @@ static char *(features[]) =
static int included_patches[] =
{ /* Add new patch number below this line */
+/**/
+189,
/**/
188,
/**/
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/E1rn1AV-00DRxq-Un%40256bit.org.
Commit: patch 9.0.2166: Memory leak in Configure Script when checking GTK
patch 9.0.2166: Memory leak in Configure Script when checking GTK
Commit:
https://github.com/vim/vim/commit/549f8c0b4ebe47168c98f46c8b62b1eb33da7c9c
Author: Zdenek Dohnal
Date: Thu Dec 14 20:22:49 2023 +0100
patch 9.0.2166: Memory leak in Configure Script when checking GTK
Problem: Memory leak in Configure Script when checking GTK
Solution: Free the allocated memory
If the memory is not freed, GTK GUI VIM cannot be build with address
sanitizer for debugging purposes - configure script will report missing
GTK, because the testing file compilation fails due reported memory
leak.
closes: #13672
Signed-off-by: Zdenek Dohnal
Signed-off-by: Christian Brabandt
diff --git a/src/auto/configure b/src/auto/configure
index 8582298ca..70ebb33c4 100755
--- a/src/auto/configure
+++ b/src/auto/configure
@@ -10136,9 +10136,12 @@ system ("touch conf.gtktest");
tmp_version = g_strdup("$min_gtk_version");
if (sscanf(tmp_version, "%d.%d.%d", , , ) != 3) {
printf("%s, bad version string
", "$min_gtk_version");
+ g_free(tmp_version);
exit(1);
}
+g_free(tmp_version);
+
if ((gtk_major_version > major) ||
((gtk_major_version == major) && (gtk_minor_version > minor)) ||
((gtk_major_version == major) && (gtk_minor_version == minor) &&
diff --git a/src/configure.ac b/src/configure.ac
index 2ee9b0182..ebe0d08f6 100644
--- a/src/configure.ac
+++ b/src/configure.ac
@@ -2700,9 +2700,12 @@ system ("touch conf.gtktest");
tmp_version = g_strdup("$min_gtk_version");
if (sscanf(tmp_version, "%d.%d.%d", , , ) != 3) {
printf("%s, bad version string
", "$min_gtk_version");
+ g_free(tmp_version);
exit(1);
}
+g_free(tmp_version);
+
if ((gtk_major_version > major) ||
((gtk_major_version == major) && (gtk_minor_version > minor)) ||
((gtk_major_version == major) && (gtk_minor_version == minor) &&
diff --git a/src/version.c b/src/version.c
index 6c9bb4506..a2623b8c4 100644
--- a/src/version.c
+++ b/src/version.c
@@ -704,6 +704,8 @@ static char *(features[]) =
static int included_patches[] =
{ /* Add new patch number below this line */
+/**/
+2166,
/**/
2165,
/**/
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/E1rDrPJ-0028my-FC%40256bit.org.
Commit: patch 9.0.1941: Memory leak detected
patch 9.0.1941: Memory leak detected
Commit:
https://github.com/vim/vim/commit/3aa114463f0219eba2e9fe0517067be9fcaf8248
Author: Yegappan Lakshmanan
Date: Mon Sep 25 12:13:17 2023 +0200
patch 9.0.1941: Memory leak detected
Problem: Memory leak detected (after 9.0.1928)
Solution: Free arg_objm in get_lambda_tv()
closes: #13181
Signed-off-by: Christian Brabandt
Co-authored-by: Yegappan Lakshmanan
diff --git a/src/userfunc.c b/src/userfunc.c
index a27ff984d..e0c1d5f91 100644
--- a/src/userfunc.c
+++ b/src/userfunc.c
@@ -1721,7 +1721,10 @@ theend:
eval_lavars_used = old_eval_lavars;
vim_free(tofree2);
if (types_optional)
+{
ga_clear_strings();
+ ga_clear(_objm);
+}
return OK;
@@ -1732,6 +1735,7 @@ errret:
if (types_optional)
{
ga_clear_strings();
+ ga_clear(_objm);
if (fp != NULL)
vim_free(fp->uf_arg_types);
}
diff --git a/src/version.c b/src/version.c
index 1d3ce5ec9..168c10cac 100644
--- a/src/version.c
+++ b/src/version.c
@@ -699,6 +699,8 @@ static char *(features[]) =
static int included_patches[] =
{ /* Add new patch number below this line */
+/**/
+1941,
/**/
1940,
/**/
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/E1qkiqr-00AsSq-Mz%40256bit.org.
Fix for the CI asan test failure due to a memory leak
Hi all, The CI ASAN test is currently failing due to a memory leak. The fix for this is in the https://github.com/vim/vim/pull/12948 PR. Regards, Yegappan -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAAW7x7mpzffs%3Dd%3DCTqVb7bhpBu0B%3Dqa9ouhSUaMO2ULjbfyMSQ%40mail.gmail.com.
Re: Valgrind reports bogus memory leak
Christian wrote: > On Sa, 28 Sep 2019, Bram Moolenaar wrote: > > > Valgrind has been reporting a leak when running test_popupwin. > > I narrowed it down to Test_simple_popup(), somewhere halfway. > > Hm, #5003 sounds like it could fix this? Strange, I didn't get an email for that pull request. It does appear to fix the problem. Thus instead of valgrind giving a false alarm for the 8-byte string, it's the opposite: It only warns for an 8-byte string and not for others. Weird. -- Advice to worms: Sleep late. /// 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201910011505.x91F5uHV012932%40masaka.moolenaar.net.
Re: Valgrind reports bogus memory leak
On Sa, 28 Sep 2019, Bram Moolenaar wrote: > Valgrind has been reporting a leak when running test_popupwin. > I narrowed it down to Test_simple_popup(), somewhere halfway. Hm, #5003 sounds like it could fix this? Best, Christian -- Wer Erfolg haben will, muß die zwischenmenschlichen Beziehungen verbessern. -- Böckmann, Walter, Dr. Böckmann, Walter, Dr. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20191001085716.GA1429%40256bit.org.
Re: Valgrind reports bogus memory leak
Stucki wrote: > > When I change "set nrformats-=octal" in defaults.vim to something that > > is not 8 bytes, then the report goes away. > > If I set another buffer-local variable to a value with 8 bytes that > > one is also reported. I don't think Vim itself does something special > > for an 8 byte string. > > Strange ... BUT, could you try to run the test with binaries > compiled with different 'compiler optimisation levels'. We once > had an error, which went away, if we lowered/raised the level > form our default=2 only on 2 it happened, and then we noticed > it happened only on a specific kind of CPU. Something in the > combination of possible registers on the CPU and the way the > parameters of routines were handled by optimizing, lost one > word of memory and potentially crashed the program. Crashes > happened on a small subset of our desktop PCs. I tried with -g (no optimization) -O1, -O2 and got the same results. My CPU is a Ryzen 2700X -- "Hegel was right when he said that we learn from history that man can never learn anything from history." (George Bernard Shaw) /// 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201909301836.x8UIaj0K018721%40masaka.moolenaar.net.
Re: Valgrind reports bogus memory leak
On Sun, 29 Sep 2019, Bram Moolenaar wrote: > When I change "set nrformats-=octal" in defaults.vim to something that > is not 8 bytes, then the report goes away. > If I set another buffer-local variable to a value with 8 bytes that > one is also reported. I don't think Vim itself does something special > for an 8 byte string. Strange ... BUT, could you try to run the test with binaries compiled with different 'compiler optimisation levels'. We once had an error, which went away, if we lowered/raised the level form our default=2 only on 2 it happened, and then we noticed it happened only on a specific kind of CPU. Something in the combination of possible registers on the CPU and the way the parameters of routines were handled by optimizing, lost one word of memory and potentially crashed the program. Crashes happened on a small subset of our desktop PCs. Stucki -- Christoph von Stuckrad* * | also XMPP = |Mail \ Freie Universitaet Berlin |/_*| 'jabber' via|Tel(Di.,Fr.):+49 30 77 39 6600| IT Mathematik & Informatik|\ *|stucki@jabber| (Mo,Mi,Do):+49 30 838-75 459| Takustr. 9 / 14195 Berlin * * |.fu-berlin.de|Fax(@home): +49 30 77 39 6601/ -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20190929214442.mpv6kfponkyjzzas%40localhost.mi.fu-berlin.de.
Re: Valgrind reports bogus memory leak
Christian wrote: > On Sa, 28 Sep 2019, Bram Moolenaar wrote: > > > > > Valgrind has been reporting a leak when running test_popupwin. > > I narrowed it down to Test_simple_popup(), somewhere halfway. > > > > The valgrind report is: > > > > ==22433== 8 bytes in 1 blocks are definitely lost in loss record 17 of 371 > > ==22433==at 0x483874F: malloc (in > > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > > ==22433==by 0x280E74: lalloc (misc2.c:924) > > ==22433==by 0x280D1F: alloc (misc2.c:827) > > ==22433==by 0x281395: vim_strsave (misc2.c:1276) > > ==22433==by 0x2BAA4A: buf_copy_options (option.c:5848) > > ==22433==by 0x1872E4: buflist_new (buffer.c:2116) > > ==22433==by 0x2D3AA9: popup_create (popupwin.c:1706) > > ==22433==by 0x2D430A: f_popup_create (popupwin.c:1923) > > > > The buf_copy_options() line is: > > > > buf->b_p_nf = vim_strsave(p_nf); > > > > This is very strange, since several other buffer-local options are > > allocated, and they are not reported. > > > > I did quite a bit of digging and finally found that this line in > > defaults.vim triggers it: > > > > set nrformats-=octal > > > > I tried setting other options there, and got confusing results, until I > > figured the leak is only reported if the string is exactly 8 bytes! That > > is 7 text characters plus NUL. If I change nrformats to only "hex" or > > make it "hex,hex,hex" then the leak is not reported. > > > > I assume this must be a bug in valgrind. Can't find anything about it > > though. > > What version of valgrind are you running? I wonder if we should report > this at bugs.kde.org. Is there an easy way to reproduce this? valgrind-3.14.0 "make test_popupwin" with valgrind enabled in src/testdir/Makefile. One would have to try out what can be left out without making the problem disappear. Dominique wrote: > It's not impossible to find a bug with valgrind, but I think it's more likely > to be a real bug with vim. When I change "set nrformats-=octal" in defaults.vim to something that is not 8 bytes, then the report goes away. If I set another buffer-local variable to a value with 8 bytes that one is also reported. I don't think Vim itself does something special for an 8 byte string. -- ARTHUR: I am your king! WOMAN: Well, I didn't vote for you. ARTHUR: You don't vote for kings. WOMAN: Well, 'ow did you become king then? The Quest for the Holy Grail (Monty Python) /// 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201909291225.x8TCPCiJ024028%40masaka.moolenaar.net.
Re: Valgrind reports bogus memory leak
Bram Moolenaar wrote: > Valgrind has been reporting a leak when running test_popupwin. > I narrowed it down to Test_simple_popup(), somewhere halfway. > > The valgrind report is: > > ==22433== 8 bytes in 1 blocks are definitely lost in loss record 17 of 371 > ==22433==at 0x483874F: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==22433==by 0x280E74: lalloc (misc2.c:924) > ==22433==by 0x280D1F: alloc (misc2.c:827) > ==22433==by 0x281395: vim_strsave (misc2.c:1276) > ==22433==by 0x2BAA4A: buf_copy_options (option.c:5848) > ==22433==by 0x1872E4: buflist_new (buffer.c:2116) > ==22433==by 0x2D3AA9: popup_create (popupwin.c:1706) > ==22433==by 0x2D430A: f_popup_create (popupwin.c:1923) > > The buf_copy_options() line is: > > buf->b_p_nf = vim_strsave(p_nf); > > This is very strange, since several other buffer-local options are > allocated, and they are not reported. > > I did quite a bit of digging and finally found that this line in > defaults.vim triggers it: > > set nrformats-=octal > > I tried setting other options there, and got confusing results, until I > figured the leak is only reported if the string is exactly 8 bytes! That > is 7 text characters plus NUL. If I change nrformats to only "hex" or > make it "hex,hex,hex" then the leak is not reported. > > I assume this must be a bug in valgrind. Can't find anything about it > though. Does it mean that you can reproduce the leak with something like: $ valgrind --leak-check=full vim --clean -c 'set nrformats-=octal' -c q If not, what is the minimalistic way of reproducing the leak? The above command does not leak for me. It's not impossible to find a bug with valgrind, but I think it's more likely to be a real bug with vim. Regards Dominique -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAON-T_jAARgA0wr%3DBymu1yEkJvWWYJP9VN2295uSMH0a_EVAvA%40mail.gmail.com.
Re: Valgrind reports bogus memory leak
On Sa, 28 Sep 2019, Bram Moolenaar wrote: > > Valgrind has been reporting a leak when running test_popupwin. > I narrowed it down to Test_simple_popup(), somewhere halfway. > > The valgrind report is: > > ==22433== 8 bytes in 1 blocks are definitely lost in loss record 17 of 371 > ==22433==at 0x483874F: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==22433==by 0x280E74: lalloc (misc2.c:924) > ==22433==by 0x280D1F: alloc (misc2.c:827) > ==22433==by 0x281395: vim_strsave (misc2.c:1276) > ==22433==by 0x2BAA4A: buf_copy_options (option.c:5848) > ==22433==by 0x1872E4: buflist_new (buffer.c:2116) > ==22433==by 0x2D3AA9: popup_create (popupwin.c:1706) > ==22433==by 0x2D430A: f_popup_create (popupwin.c:1923) > > The buf_copy_options() line is: > > buf->b_p_nf = vim_strsave(p_nf); > > This is very strange, since several other buffer-local options are > allocated, and they are not reported. > > I did quite a bit of digging and finally found that this line in > defaults.vim triggers it: > > set nrformats-=octal > > I tried setting other options there, and got confusing results, until I > figured the leak is only reported if the string is exactly 8 bytes! That > is 7 text characters plus NUL. If I change nrformats to only "hex" or > make it "hex,hex,hex" then the leak is not reported. > > I assume this must be a bug in valgrind. Can't find anything about it > though. What version of valgrind are you running? I wonder if we should report this at bugs.kde.org. Is there an easy way to reproduce this? Best, Christian -- Sorgen sind wie Babies: Je mehr man sie hätschelt, desto besser gedeihen sie. -- Helmut Qualtinger -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20190929083418.GA9133%40256bit.org.
Valgrind reports bogus memory leak
Valgrind has been reporting a leak when running test_popupwin. I narrowed it down to Test_simple_popup(), somewhere halfway. The valgrind report is: ==22433== 8 bytes in 1 blocks are definitely lost in loss record 17 of 371 ==22433==at 0x483874F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==22433==by 0x280E74: lalloc (misc2.c:924) ==22433==by 0x280D1F: alloc (misc2.c:827) ==22433==by 0x281395: vim_strsave (misc2.c:1276) ==22433==by 0x2BAA4A: buf_copy_options (option.c:5848) ==22433==by 0x1872E4: buflist_new (buffer.c:2116) ==22433==by 0x2D3AA9: popup_create (popupwin.c:1706) ==22433==by 0x2D430A: f_popup_create (popupwin.c:1923) The buf_copy_options() line is: buf->b_p_nf = vim_strsave(p_nf); This is very strange, since several other buffer-local options are allocated, and they are not reported. I did quite a bit of digging and finally found that this line in defaults.vim triggers it: set nrformats-=octal I tried setting other options there, and got confusing results, until I figured the leak is only reported if the string is exactly 8 bytes! That is 7 text characters plus NUL. If I change nrformats to only "hex" or make it "hex,hex,hex" then the leak is not reported. I assume this must be a bug in valgrind. Can't find anything about it though. -- WOMAN: Dennis, there's some lovely filth down here. Oh -- how d'you do? ARTHUR: How do you do, good lady. I am Arthur, King of the Britons. Who's castle is that? WOMAN: King of the who? The Quest for the Holy Grail (Monty Python) /// 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201909281238.x8SCctON025139%40masaka.moolenaar.net.
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.
Memory leak reported by valgrind in set_init_1()
Hi, 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. - Yegappan -- -- 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: Patch to fix a memory leak when vimgrep fails
Yegappan wrote: > Running the quickfix tests under valgrind reports a memory > leak when vimgrep fails. The attached patch fixes this leak. Thanks! -- "The question of whether computers can think is just like the question of whether submarines can swim." -- Edsger W. Dijkstra /// 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.
Patch to fix a memory leak when vimgrep fails
Hi, Running the quickfix tests under valgrind reports a memory leak when vimgrep fails. The attached patch fixes this leak. - Yegappan -- -- 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. memleak.diff Description: Binary data
Weird memory leak, possible compiler bug
I noticed that when running test97 under valgrind a memory leak is
reported:
==6523== 11 bytes in 1 blocks are possibly lost in loss record 114 of 720
==6523==at 0x4C2CB3F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6523==by 0x255A29: lalloc (misc2.c:942)
==6523==by 0x2558F4: alloc (misc2.c:840)
==6523==by 0x255EE1: vim_strsave (misc2.c:1285)
==6523==by 0x19ECCD: get_env_tv (eval.c:6012)
==6523==by 0x19B808: eval7 (eval.c:4263)
==6523==by 0x19B1F0: eval6 (eval.c:3969)
==6523==by 0x19ACCF: eval5 (eval.c:3785)
==6523==by 0x199F39: eval4 (eval.c:3484)
==6523==by 0x199D63: eval3 (eval.c:3401)
==6523==by 0x199BB9: eval2 (eval.c:)
==6523==by 0x1999CB: eval1 (eval.c:3261)
==6523==by 0x1998FF: eval0 (eval.c:3221)
==6523==by 0x1955D6: ex_let (eval.c:1228)
==6523==by 0x1DA61E: do_one_cmd (ex_docmd.c:2981)
==6523==by 0x1D6F26: do_cmdline (ex_docmd.c:1120)
==6523==by 0x1D4A88: do_source (ex_cmds2.c:4306)
==6523==by 0x3CA636: source_startup_scripts (main.c:2961)
==6523==by 0x3C6C89: vim_main2 (main.c:439)
==6523==by 0x3C6C0F: main (main.c:415)
I'm quite sure the let statement involved is in testdir/unix.vim:
let g:tester_HOME = $HOME
Removing that statement makes the leak go away.
By trying various things I can make the memory leak disappear, but it
doesn't make any sense.
First of all, changing test97.in to exit early:
:e! test.out
:$put =glob('Xxx\{')
:$put =glob('Xxx\$')
inserting qa! here does not have the leak
:w! Xxx{
inserting qa! here still does have the leak
:w! Xxx\$
:$put =glob('Xxx\{')
:$put =glob('Xxx\$')
:"
The write command does something with wildcard expansion, but it doesn't
touch g:tester_HOME.
Another way to get rid of the leak, which is even weirder:
*** ../vim-8.0.0376/src/eval.c 2017-02-25 21:39:13.300021243 +0100
--- src/eval.c 2017-02-26 17:26:51.691938173 +0100
***
*** 345,350
--- 345,352
#endif
}
+ char_u *saved_string = NULL;
+
#if defined(EXITFREE) || defined(PROTO)
void
eval_clear(void)
***
*** 377,382
--- 379,385
/* global variables */
vars_clear();
+ saved_string = NULL;
/* autoloaded script names */
ga_clear_strings(_loaded);
***
*** 6006,6012
--- 6009,6018
if (string != NULL && *string != NUL)
{
if (!mustfree)
+ {
string = vim_strsave(string);
+ saved_string = string;
+ }
}
else
{
Note that "saved_string" is cleared before exit, otherwise valgrind
thinks it's still referenced.
This is supposed not to have any effect, it just copies a pointer.
Still, adding this avoids the leak. This smells like a compiler bug.
I am using "gcc -g", no optimizer set. I tried -O0 and -Og, does not
make a difference.
I also checked that vim_free() is called for the saved string, it is.
But when I do that the leak isn't reported (storing the pointer in
saved_string as above).
However, when clearing saved_string just before get_env_tv() returns
makes the leak reappear. But then we can't check if vim_free() is
called with that pointer.
Another way: instead of remembering the pointer as-is, I print the value
into a buffer:
sprintf(saved_string, "%lx", (long)string);
Then check in vim_free() if it is freed:
if (x != NULL)
{
char buf[20];
sprintf(buf, "%lx", (long)x);
if (STRCMP(buf, saved_string) == 0)
ch_log(NULL, "saved_string freed");
}
And it is reported to be freed. Valgrind still reports the leak.
I'm confused. Perhaps valgrind is wrong?
--
How To Keep A Healthy Level Of Insanity:
4. Put your garbage can on your desk and label it "in".
/// 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: [bug] memory leak with getbufinfo() and signs in Vim-7.4.2275
Yegappan Lakshmanan wrote:
> On Sun, Aug 28, 2016 at 1:56 AM, Dominique Pell=C3=A9
> <dominique.pe...@gmail.com> wrote:
> > Hi
> >
> > I see a memory leak in Vim-7.4.2275 which can be
> > reproduced by:
> >
> > $ valgrind --leak-check=3Dyes --num-callers=3D50 \
> >vim -u NONE -N \
> >-c 'sign define Sign text=3Dx' \
> >-c 'exe "sign place 1 line=3D3 name=3DSign buffer=3D" . bufnr("%")' \
> >-c 'echo getbufinfo()' \
> >-c q 2> log
> >
>
> Can you try the attached patch?
I just sent out a patch with the same change. It fixes the problem.
--
There's no place like $(HOME)!
/// 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: [bug] memory leak with getbufinfo() and signs in Vim-7.4.2275
Dominique Pellé wrote:
> I see a memory leak in Vim-7.4.2275 which can be
> reproduced by:
>
> $ valgrind --leak-check=yes --num-callers=50 \
>vim -u NONE -N \
>-c 'sign define Sign text=x' \
>-c 'exe "sign place 1 line=3 name=Sign buffer=" . bufnr("%")' \
>-c 'echo getbufinfo()' \
>-c q 2> log
>
> And log file contains:
>
> ==11611== Memcheck, a memory error detector
> ==11611== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==11611== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
> ==11611== Command: ./vim -u NONE -N -c sign\ define\ Sign\ text=x -c
> exe\ "sign\ place\ 1\ line=3\ name=Sign\ buffer="\ .\ bufnr("%") -c
> echo\ getbufinfo()
> ==11611==
> ==11611==
> ==11611== HEAP SUMMARY:
> ==11611== in use at exit: 51,696 bytes in 868 blocks
> ==11611== total heap usage: 11,596 allocs, 10,728 frees, 1,002,877
> bytes allocated
> ==11611==
> ==11611== 5 bytes in 1 blocks are definitely lost in loss record 8 of 125
> ==11611==at 0x402C19C: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==11611==by 0x810CA44: lalloc (misc2.c:920)
> ==11611==by 0x810D32C: alloc (misc2.c:818)
> ==11611==by 0x810D32C: vim_strsave (misc2.c:1263)
> ==11611==by 0x8092058: get_buffer_signs (evalfunc.c:3908)
> ==11611==by 0x8092058: get_buffer_info (evalfunc.c:3964)
> ==11611==by 0x8092058: f_getbufinfo (evalfunc.c:4029)
> ==11611==by 0x809191E: call_internal_func (evalfunc.c:997)
> ==11611==by 0x81C3F1C: call_func (userfunc.c:1372)
> ==11611==by 0x81C506B: get_func_tv (userfunc.c:455)
> ==11611==by 0x8078753: eval7 (eval.c:4343)
> ==11611==by 0x807886D: eval6 (eval.c:3977)
> ==11611==by 0x8078B77: eval5 (eval.c:3793)
> ==11611==by 0x8079909: eval4 (eval.c:3492)
> ==11611==by 0x8079909: eval3 (eval.c:3409)
> ==11611==by 0x8079A9F: eval2 (eval.c:3341)
> ==11611==by 0x8079A9F: eval1 (eval.c:3269)
> ==11611==by 0x807B9EC: ex_echo (eval.c:8175)
> ==11611==by 0x80B0FD4: do_one_cmd (ex_docmd.c:2967)
> ==11611==by 0x80B0FD4: do_cmdline (ex_docmd.c:1110)
> ==11611==by 0x80B4CA1: do_cmdline_cmd (ex_docmd.c:715)
> ==11611==by 0x81E2041: exe_commands (main.c:2896)
> ==11611==by 0x81E2041: vim_main2 (main.c:781)
> ==11611==by 0x804E03B: main (main.c:415)
>
> Running ":echo getbufinfo()" N times results in N blocks
> being leaked.
>
> Vim was configured with:
> $ ./configure --with-features=huge --enable-gui=none
> And EXITFREE was define in src/Makefile.
Thanks. It's simply doing a vim_strsave() that isn't needed.
--
>From "know your smileys":
:-&Eating spaghetti
/// 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: [bug] memory leak with getbufinfo() and signs in Vim-7.4.2275
Hi Dominique,
On Sun, Aug 28, 2016 at 1:56 AM, Dominique Pellé
<dominique.pe...@gmail.com> wrote:
> Hi
>
> I see a memory leak in Vim-7.4.2275 which can be
> reproduced by:
>
> $ valgrind --leak-check=yes --num-callers=50 \
>vim -u NONE -N \
>-c 'sign define Sign text=x' \
>-c 'exe "sign place 1 line=3 name=Sign buffer=" . bufnr("%")' \
>-c 'echo getbufinfo()' \
>-c q 2> log
>
Can you try the attached patch?
Thanks,
Yegappan
>
> And log file contains:
>
> ==11611== Memcheck, a memory error detector
> ==11611== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==11611== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
> ==11611== Command: ./vim -u NONE -N -c sign\ define\ Sign\ text=x -c
> exe\ "sign\ place\ 1\ line=3\ name=Sign\ buffer="\ .\ bufnr("%") -c
> echo\ getbufinfo()
> ==11611==
> ==11611==
> ==11611== HEAP SUMMARY:
> ==11611== in use at exit: 51,696 bytes in 868 blocks
> ==11611== total heap usage: 11,596 allocs, 10,728 frees, 1,002,877
> bytes allocated
> ==11611==
> ==11611== 5 bytes in 1 blocks are definitely lost in loss record 8 of 125
> ==11611==at 0x402C19C: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==11611==by 0x810CA44: lalloc (misc2.c:920)
> ==11611==by 0x810D32C: alloc (misc2.c:818)
> ==11611==by 0x810D32C: vim_strsave (misc2.c:1263)
> ==11611==by 0x8092058: get_buffer_signs (evalfunc.c:3908)
> ==11611==by 0x8092058: get_buffer_info (evalfunc.c:3964)
> ==11611==by 0x8092058: f_getbufinfo (evalfunc.c:4029)
> ==11611==by 0x809191E: call_internal_func (evalfunc.c:997)
> ==11611==by 0x81C3F1C: call_func (userfunc.c:1372)
> ==11611==by 0x81C506B: get_func_tv (userfunc.c:455)
> ==11611==by 0x8078753: eval7 (eval.c:4343)
> ==11611==by 0x807886D: eval6 (eval.c:3977)
> ==11611==by 0x8078B77: eval5 (eval.c:3793)
> ==11611==by 0x8079909: eval4 (eval.c:3492)
> ==11611==by 0x8079909: eval3 (eval.c:3409)
> ==11611==by 0x8079A9F: eval2 (eval.c:3341)
> ==11611==by 0x8079A9F: eval1 (eval.c:3269)
> ==11611==by 0x807B9EC: ex_echo (eval.c:8175)
> ==11611==by 0x80B0FD4: do_one_cmd (ex_docmd.c:2967)
> ==11611==by 0x80B0FD4: do_cmdline (ex_docmd.c:1110)
> ==11611==by 0x80B4CA1: do_cmdline_cmd (ex_docmd.c:715)
> ==11611==by 0x81E2041: exe_commands (main.c:2896)
> ==11611==by 0x81E2041: vim_main2 (main.c:781)
> ==11611==by 0x804E03B: main (main.c:415)
>
> Running ":echo getbufinfo()" N times results in N blocks
> being leaked.
>
> Vim was configured with:
> $ ./configure --with-features=huge --enable-gui=none
> And EXITFREE was define in src/Makefile.
>
> Regards
> Dominique
>
--
--
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.
diff --git a/src/evalfunc.c b/src/evalfunc.c
index 7ccf524..769532b 100644
--- a/src/evalfunc.c
+++ b/src/evalfunc.c
@@ -3905,8 +3905,7 @@ get_buffer_signs(buf_T *buf, list_T *l)
{
dict_add_nr_str(d, "id", sign->id, NULL);
dict_add_nr_str(d, "lnum", sign->lnum, NULL);
- dict_add_nr_str(d, "name", 0L,
- vim_strsave(sign_typenr2name(sign->typenr)));
+ dict_add_nr_str(d, "name", 0L, sign_typenr2name(sign->typenr));
list_append_dict(l, d);
}
[bug] memory leak with getbufinfo() and signs in Vim-7.4.2275
Hi
I see a memory leak in Vim-7.4.2275 which can be
reproduced by:
$ valgrind --leak-check=yes --num-callers=50 \
vim -u NONE -N \
-c 'sign define Sign text=x' \
-c 'exe "sign place 1 line=3 name=Sign buffer=" . bufnr("%")' \
-c 'echo getbufinfo()' \
-c q 2> log
And log file contains:
==11611== Memcheck, a memory error detector
==11611== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11611== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==11611== Command: ./vim -u NONE -N -c sign\ define\ Sign\ text=x -c
exe\ "sign\ place\ 1\ line=3\ name=Sign\ buffer="\ .\ bufnr("%") -c
echo\ getbufinfo()
==11611==
==11611==
==11611== HEAP SUMMARY:
==11611== in use at exit: 51,696 bytes in 868 blocks
==11611== total heap usage: 11,596 allocs, 10,728 frees, 1,002,877
bytes allocated
==11611==
==11611== 5 bytes in 1 blocks are definitely lost in loss record 8 of 125
==11611==at 0x402C19C: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==11611==by 0x810CA44: lalloc (misc2.c:920)
==11611==by 0x810D32C: alloc (misc2.c:818)
==11611==by 0x810D32C: vim_strsave (misc2.c:1263)
==11611==by 0x8092058: get_buffer_signs (evalfunc.c:3908)
==11611==by 0x8092058: get_buffer_info (evalfunc.c:3964)
==11611==by 0x8092058: f_getbufinfo (evalfunc.c:4029)
==11611==by 0x809191E: call_internal_func (evalfunc.c:997)
==11611==by 0x81C3F1C: call_func (userfunc.c:1372)
==11611==by 0x81C506B: get_func_tv (userfunc.c:455)
==11611==by 0x8078753: eval7 (eval.c:4343)
==11611==by 0x807886D: eval6 (eval.c:3977)
==11611==by 0x8078B77: eval5 (eval.c:3793)
==11611==by 0x8079909: eval4 (eval.c:3492)
==11611==by 0x8079909: eval3 (eval.c:3409)
==11611==by 0x8079A9F: eval2 (eval.c:3341)
==11611==by 0x8079A9F: eval1 (eval.c:3269)
==11611==by 0x807B9EC: ex_echo (eval.c:8175)
==11611==by 0x80B0FD4: do_one_cmd (ex_docmd.c:2967)
==11611==by 0x80B0FD4: do_cmdline (ex_docmd.c:1110)
==11611==by 0x80B4CA1: do_cmdline_cmd (ex_docmd.c:715)
==11611==by 0x81E2041: exe_commands (main.c:2896)
==11611==by 0x81E2041: vim_main2 (main.c:781)
==11611==by 0x804E03B: main (main.c:415)
Running ":echo getbufinfo()" N times results in N blocks
being leaked.
Vim was configured with:
$ ./configure --with-features=huge --enable-gui=none
And EXITFREE was define in src/Makefile.
Regards
Dominique
--
--
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: [patch] found memory leak in do_ecmd()
Hirohito Higashi wrote: > Hi Bram and list, > > I found memory leak in do_ecmd(). > > If u_savecommon() is FAIL, then `new_name` does not freed. > I wrote a patch. > Check it please. Thanks! -- Girls are like internet domain names, the ones I like are already taken. Well, you can stil get one from a strange country :-P /// 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.
[patch] found memory leak in do_ecmd()
Hi Bram and list,
I found memory leak in do_ecmd().
If u_savecommon() is FAIL, then `new_name` does not freed.
I wrote a patch.
Check it please.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)
--
--
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.
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
index 860d3dc..e40e435 100644
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -4091,7 +4091,10 @@ do_ecmd(
u_sync(FALSE);
if (u_savecommon(0, curbuf->b_ml.ml_line_count + 1, 0, TRUE)
== FAIL)
+ {
+ vim_free(new_name);
goto theend;
+ }
u_unchanged(curbuf);
buf_freeall(curbuf, BFA_KEEP_UNDO);
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.
Memory leak in find_some_match()
Hi, 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. - Yegappan -- -- 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. diff --git a/src/eval.c b/src/eval.c index 3578c99..8bc4a39 100644 --- a/src/eval.c +++ b/src/eval.c @@ -15735,6 +15735,8 @@ find_some_match(typval_T *argvars, typval_T *rettv, int type) listitem_T *li3 = li2->li_next; listitem_T *li4 = li3->li_next; + if (li1->li_tv.vval.v_string != NULL) + vim_free(li1->li_tv.vval.v_string); li1->li_tv.vval.v_string = vim_strnsave(regmatch.startp[0], (int)(regmatch.endp[0] - regmatch.startp[0])); li3->li_tv.vval.v_number =
Re: [patch] Possible memory leak with partial
Thinca wrote:
> Thank you for the patch!
>
> I found a SEGV pattern with this patch.
>
> " test.vim
> let obj = {}
> function! obj.func() abort
> endfunction
> let obj.func = obj.func
> unlet obj
> call garbagecollect()
>
>
> vim -u test.vim -i NONE -N
That's actually an existing problem, uncovered by correctly
unreferencing tv_dict. I'll fix it. It's not that easy, since a dict
can contain a partial and a partial can contain a dict.
--
hundred-and-one symptoms of being an internet addict:
98. The Alta Vista administrators ask you what sites are missing
in their index files.
/// 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: [patch] Possible memory leak with partial
Ken Takata wrote;
> The last assert_false() in the following script fails after 7.4.1577:
> (This is reported by Thinca.)
>
> let obj = {}
> function! obj.func() abort
> endfunction
> let funcnumber = matchstr(string(obj.func), '^function(''\zs.\{-}\ze''')
> call assert_true(exists('*{' . funcnumber . '}'))
> unlet obj
> call assert_false(exists('*{' . funcnumber . '}'))
>
>
> It seems that obj.func() is not freed.
> I think that the following patch fixes the problem, but I'm not sure:
Good catch! It does look like the right solution. I'll add a comment
about why it happens this way: When using the VAR_FUNC name we don't
copy but take over the value, thus should not increment the refcount.
--
hundred-and-one symptoms of being an internet addict:
96. On Super Bowl Sunday, you followed the score by going to the
Yahoo main page instead of turning on the TV.
/// 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: [patch] Possible memory leak with partial
Thank you for the patch!
I found a SEGV pattern with this patch.
" test.vim
let obj = {}
function! obj.func() abort
endfunction
let obj.func = obj.func
unlet obj
call garbagecollect()
vim -u test.vim -i NONE -N
#0 0x74afd6e7 in raise () from /lib64/libc.so.6
#1 0x74afeaba in abort () from /lib64/libc.so.6
#2 0x74b3c1e0 in __libc_message () from /lib64/libc.so.6
#3 0x74b4169e in malloc_printerr () from /lib64/libc.so.6
#4 0x74b41e8b in _int_free () from /lib64/libc.so.6
#5 0x005366e0 in vim_free (x=0xca47c0) at misc2.c:1695
#6 0x0047f57d in dict_free (d=0xca47c0, recurse=0) at eval.c:7284
#7 0x0047ef0c in free_unref_items (copyID=2) at eval.c:7001
#8 0x0047ee0c in garbage_collect () at eval.c:6949
#9 0x004f4c05 in vgetc () at getchar.c:1574
#10 0x004f51e6 in safe_vgetc () at getchar.c:1801
#11 0x0054759a in normal_cmd (oap=0x7fffdb30, toplevel=1)
at normal.c:627
#12 0x0068bf34 in main_loop (cmdwin=0, noexmode=0) at main.c:1353
#13 0x0068b84b in main (argc=7, argv=0x7fffde48) at main.c:1045
--
thinca
--
--
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.
[patch] Possible memory leak with partial
Hi,
The last assert_false() in the following script fails after 7.4.1577:
(This is reported by Thinca.)
let obj = {}
function! obj.func() abort
endfunction
let funcnumber = matchstr(string(obj.func), '^function(''\zs.\{-}\ze''')
call assert_true(exists('*{' . funcnumber . '}'))
unlet obj
call assert_false(exists('*{' . funcnumber . '}'))
It seems that obj.func() is not freed.
I think that the following patch fixes the problem, but I'm not sure:
--- a/src/eval.c
+++ b/src/eval.c
@@ -12038,6 +12038,7 @@ partial_free(partial_T *pt)
clear_tv(>pt_argv[i]);
vim_free(pt->pt_argv);
func_unref(pt->pt_name);
+dict_unref(pt->pt_dict);
vim_free(pt->pt_name);
vim_free(pt);
}
@@ -21846,9 +21847,9 @@ handle_subscript(
copy_tv(_pt->pt_argv[i], >pt_argv[i]);
}
}
+ func_ref(pt->pt_name);
partial_unref(ret_pt);
}
- func_ref(pt->pt_name);
rettv->v_type = VAR_PARTIAL;
rettv->vval.v_partial = pt;
}
Regards,
Ken Takata
--
--
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.
Memory leak in ex_vimgrep()
Hi all,
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.
- Yegappan
--
--
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.
diff --git a/src/quickfix.c b/src/quickfix.c
index 003d007..21ac1c0 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -3465,7 +3465,10 @@ ex_vimgrep(eap)
dirname_start = alloc_id(MAXPATHL, aid_qf_dirname_start);
dirname_now = alloc_id(MAXPATHL, aid_qf_dirname_now);
if (dirname_start == NULL || dirname_now == NULL)
+{
+ FreeWild(fcount, fnames);
goto theend;
+}
/* Remember the current directory, because a BufRead autocommand that does
* ":lcd %:p:h" changes the meaning of short path names. */
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: [patch] fixed memory leak when encountering syntax error E475 or E488
Dominique Pellé wrote: > Vim-7.4.909 (and earlier) leaks memory when > encountering syntax error E475 or E488: > > ==18952== 2 bytes in 1 blocks are definitely lost in loss record 1 of 125 > ==18952==at 0x4C2AB80: malloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==18952==by 0x4E27BF: lalloc (misc2.c:921) > ==18952==by 0x4E26CD: alloc (misc2.c:820) > ==18952==by 0x4E2C13: vim_strnsave (misc2.c:1265) > ==18952==by 0x47D42B: ex_match (ex_docmd.c:12115) > ==18952==by 0x46E052: do_one_cmd (ex_docmd.c:2961) > ==18952==by 0x46AD47: do_cmdline (ex_docmd.c:1133) > ==18952==by 0x46A383: do_cmdline_cmd (ex_docmd.c:738) > ==18952==by 0x5DD756: exe_commands (main.c:2926) > ==18952==by 0x5DAD38: main (main.c:961) > > Leak with error E475 can be reproduced with: > $ vim -u NONE -c 'match x' > > Leak with error E488 can be reproduced with: > $ vim -u NONE -c 'match x "x" contains' > > Attached patch fixes it. > Bug was discovered with afl-fuzz + valgrind. Thanks! -- You are only young once, but you can stay immature indefinitely. /// 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.
[patch] fixed memory leak when encountering syntax error E475 or E488
Hi
Vim-7.4.909 (and earlier) leaks memory when
encountering syntax error E475 or E488:
==18952== 2 bytes in 1 blocks are definitely lost in loss record 1 of 125
==18952==at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18952==by 0x4E27BF: lalloc (misc2.c:921)
==18952==by 0x4E26CD: alloc (misc2.c:820)
==18952==by 0x4E2C13: vim_strnsave (misc2.c:1265)
==18952==by 0x47D42B: ex_match (ex_docmd.c:12115)
==18952==by 0x46E052: do_one_cmd (ex_docmd.c:2961)
==18952==by 0x46AD47: do_cmdline (ex_docmd.c:1133)
==18952==by 0x46A383: do_cmdline_cmd (ex_docmd.c:738)
==18952==by 0x5DD756: exe_commands (main.c:2926)
==18952==by 0x5DAD38: main (main.c:961)
Leak with error E475 can be reproduced with:
$ vim -u NONE -c 'match x'
Leak with error E488 can be reproduced with:
$ vim -u NONE -c 'match x "x" contains'
Attached patch fixes it.
Bug was discovered with afl-fuzz + valgrind.
Regards
Dominique
--
--
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.
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 23514fb..31b51e9 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -12117,6 +12117,7 @@ ex_match(eap)
if (*p == NUL)
{
/* There must be two arguments. */
+ vim_free(g);
EMSG2(_(e_invarg2), eap->arg);
return;
}
@@ -12125,11 +12126,13 @@ ex_match(eap)
{
if (*end != NUL && !ends_excmd(*skipwhite(end + 1)))
{
+ vim_free(g);
eap->errmsg = e_trailing;
return;
}
if (*end != *p)
{
+ vim_free(g);
EMSG2(_(e_invarg2), p);
return;
}
Fix crash/memory leak in some low memory situations
Hi,
There are some uses of vim_realloc() that can lead to a memory leak and
possibly an immediate crash if the call to vim_realloc() fails. A
little ironic to be leaking memory when failing trying to allocate some.
Attached is a diff against 7.4.622.
There is one occurrence I didn't fix, in regexp_nfa.c in addstate(). I
know this is very sensitive code with no obvious memory error handling
for me to work off. One for someone more comfortable in this file to fix.
Mike
--
I haven't lost it! It's been temporally mislaid.
--
--
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.
diff --git a/src/if_cscope.c b/src/if_cscope.c
--- a/src/if_cscope.c
+++ b/src/if_cscope.c
@@ -1507,9 +1507,14 @@ cs_insert_filelist(fname, ppath, flags,
}
else
{
+ csinfo_T *t_csinfo = csinfo;
/* Reallocate space for more connections. */
csinfo_size *= 2;
csinfo = vim_realloc(csinfo, sizeof(csinfo_T)*csinfo_size);
+ if (csinfo == NULL) {
+ vim_free(t_csinfo);
+ csinfo_size = 0;
+ }
}
if (csinfo == NULL)
return -1;
@@ -2059,6 +2064,7 @@ cs_print_tags_priv(matches, cntxts, num_
int num_matches;
{
char *buf = NULL;
+char *t_buf;
int bufsize = 0; /* Track available bufsize */
int newsize = 0;
char *ptag;
@@ -2120,9 +2126,13 @@ cs_print_tags_priv(matches, cntxts, num_
newsize = (int)(strlen(csfmt_str) + 16 + strlen(lno));
if (bufsize newsize)
{
+ t_buf = buf;
buf = (char *)vim_realloc(buf, newsize);
- if (buf == NULL)
+ if (buf == NULL) {
bufsize = 0;
+ if (t_buf != NULL)
+ vim_free(t_buf);
+ }
else
bufsize = newsize;
}
@@ -2143,9 +2153,13 @@ cs_print_tags_priv(matches, cntxts, num_
if (bufsize newsize)
{
+ t_buf = buf;
buf = (char *)vim_realloc(buf, newsize);
- if (buf == NULL)
+ if (buf == NULL) {
bufsize = 0;
+ if (t_buf != NULL)
+ vim_free(t_buf);
+ }
else
bufsize = newsize;
}
diff --git a/src/memline.c b/src/memline.c
--- a/src/memline.c
+++ b/src/memline.c
@@ -5057,6 +5057,7 @@ ml_updatechunk(buf, line, len, updtype)
/* May resize here so we don't have to do it in both cases below */
if (buf-b_ml.ml_usedchunks + 1 = buf-b_ml.ml_numchunks)
{
+ chunksize_T *t_chunksize = buf-b_ml.ml_chunksize;
buf-b_ml.ml_numchunks = buf-b_ml.ml_numchunks * 3 / 2;
buf-b_ml.ml_chunksize = (chunksize_T *)
vim_realloc(buf-b_ml.ml_chunksize,
@@ -5064,6 +5065,7 @@ ml_updatechunk(buf, line, len, updtype)
if (buf-b_ml.ml_chunksize == NULL)
{
/* H, Give up on offset for this buffer */
+ vim_free(t_chunksize);
buf-b_ml.ml_usedchunks = -1;
return;
}
diff --git a/src/misc1.c b/src/misc1.c
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -3431,10 +3431,13 @@ get_keystroke()
buf = alloc(buflen);
else if (maxlen 10)
{
+ char_u *t_buf = buf;
/* Need some more space. This might happen when receiving a long
* escape sequence. */
buflen += 100;
buf = vim_realloc(buf, buflen);
+ if (buf == NULL)
+ vim_free(t_buf);
maxlen = (buflen - 6 - len) / 3;
}
if (buf == NULL)
diff --git a/src/netbeans.c b/src/netbeans.c
--- a/src/netbeans.c
+++ b/src/netbeans.c
@@ -1080,10 +1080,16 @@ nb_get_buf(int bufno)
{
if (bufno = buf_list_size) /* grow list */
{
+ nbbuf_T *t_buf_list = buf_list;
incr = bufno - buf_list_size + 90;
buf_list_size += incr;
buf_list = (nbbuf_T *)vim_realloc(
buf_list, buf_list_size * sizeof(nbbuf_T));
+ if (buf_list == NULL) {
+ vim_free(t_buf_list);
+ buf_list_size = 0;
+ return NULL;
+ }
vim_memset(buf_list + buf_list_size - incr, 0,
incr * sizeof(nbbuf_T));
}
@@ -3678,11 +3684,17 @@ addsigntype(
{
int incr;
int oldlen = globalsignmaplen;
+ char **t_globalsignmap = globalsignmap;
globalsignmaplen *= 2;
incr = globalsignmaplen - oldlen;
globalsignmap = (char **)vim_realloc(globalsignmap,
globalsignmaplen * sizeof(char *));
+ if (globalsignmap == NULL) {
+ vim_free(t_globalsignmap);
+ globalsignmaplen = 0;
+ return;
+ }
vim_memset(globalsignmap + oldlen, 0, incr * sizeof(char *));
}
}
@@ -3708,11 +3720,17 @@ addsigntype(
{
int incr;
int oldlen = buf-signmaplen;
+ int *t_signmap = buf-signmap;
buf-signmaplen *= 2;
incr = buf-signmaplen - oldlen;
buf-signmap = (int *)vim_realloc(buf-signmap,
buf-signmaplen * sizeof(int));
+ if (buf-signmap == NULL) {
+ vim_free(t_signmap);
+ buf
Re: Fix crash/memory leak in some low memory situations
Mike Williams wrote: There are some uses of vim_realloc() that can lead to a memory leak and possibly an immediate crash if the call to vim_realloc() fails. A little ironic to be leaking memory when failing trying to allocate some. Attached is a diff against 7.4.622. Thanks. It's good to handle low memory situations gracefully, we don't want Vim to crash. There is one occurrence I didn't fix, in regexp_nfa.c in addstate(). I know this is very sensitive code with no obvious memory error handling for me to work off. One for someone more comfortable in this file to fix. Yeah, addstate() has grown into a complex beast while implementing all the corner cases. Handling addstate() returning NULL is going to be quite a bit of work. Perhaps a longjmp would be a better solution? It adds a fixed overhead instead of if (p != NULL) in many places. -- hundred-and-one symptoms of being an internet addict: 200. You really believe in the concept of a paperless office. /// 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: Issue 296 in vim: Memory leak when using viminfo and a vimrc
Updates: Status: Fixed Comment #3 on issue 296 by brammool...@gmail.com: Memory leak when using viminfo and a vimrc https://code.google.com/p/vim/issues/detail?id=296 Should be fixed by patch 7.4.560 -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- 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: Issue 296 in vim: Memory leak when using viminfo and a vimrc
Comment #1 on issue 296 by chrisbr...@googlemail.com: Memory leak when using viminfo and a vimrc https://code.google.com/p/vim/issues/detail?id=296 Yes, I can see it. I attach a fix. Attachments: mem_leak_fix_readviminfo.diff 1.6 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- 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: Issue 296 in vim: Memory leak when using viminfo and a vimrc
Comment #2 on issue 296 by joelteichroeb: Memory leak when using viminfo and a vimrc https://code.google.com/p/vim/issues/detail?id=296 I can confirm that fixes it. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- 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.
Issue 296 in vim: Memory leak when using viminfo and a vimrc
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 296 by joelteichroeb: Memory leak when using viminfo and a vimrc https://code.google.com/p/vim/issues/detail?id=296 What steps will reproduce the problem? 1. Create a .vimrc file 2. Start vim using valgrind or similar tool 3. Execute the following lines: :wv! Xviminfo :rv! Xviminfo 4. Notice the reported memory leak What is the expected output? What do you see instead? No memory leak. What version of the product are you using? On what operating system? vim 7.4 patch level 537 on Arch linux. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- 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.
[patch] memory leak in hardcopy.c
Bram,
there is a memory leak in hardcopy.c in the function mch_print_begin()
In case of errors it returns early, without freeing the allocated
memory.
Attached is a patch.
Best,
Christian
--
Windows 95 kann alles, wegen der 32 Bit.
Wenn ich 32 Bit getrunken habe, meine ich auch immer, ich könnte alles.
-- T. Koschwitz
--
--
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.
diff --git a/src/hardcopy.c b/src/hardcopy.c
--- a/src/hardcopy.c
+++ b/src/hardcopy.c
@@ -2960,12 +2960,12 @@ mch_print_begin(psettings)
if (!prt_find_resource(prolog, res_prolog))
{
EMSG(_(E456: Can't find PostScript resource file \prolog.ps\));
- return FALSE;
+ goto theend;
}
if (!prt_open_resource(res_prolog))
- return FALSE;
+ goto theend;
if (!prt_check_resource(res_prolog, PRT_PROLOG_VERSION))
- return FALSE;
+ goto theend;
#ifdef FEAT_MBYTE
if (prt_out_mbyte)
{
@@ -2973,12 +2973,12 @@ mch_print_begin(psettings)
if (!prt_find_resource(cidfont, res_cidfont))
{
EMSG(_(E456: Can't find PostScript resource file \cidfont.ps\));
- return FALSE;
+ goto theend;
}
if (!prt_open_resource(res_cidfont))
- return FALSE;
+ goto theend;
if (!prt_check_resource(res_cidfont, PRT_CID_PROLOG_VERSION))
- return FALSE;
+ goto theend;
}
#endif
@@ -3012,12 +3012,12 @@ mch_print_begin(psettings)
{
EMSG2(_(E456: Can't find PostScript resource file \%s.ps\),
p_encoding);
- return FALSE;
+ goto theend;
}
}
}
if (!prt_open_resource(res_encoding))
- return FALSE;
+ goto theend;
/* For the moment there are no checks on encoding resource files to
* perform */
#ifdef FEAT_MBYTE
@@ -3034,10 +3034,10 @@ mch_print_begin(psettings)
{
EMSG2(_(E456: Can't find PostScript resource file \%s.ps\),
prt_ascii_encoding);
- return FALSE;
+ goto theend;
}
if (!prt_open_resource(res_encoding))
- return FALSE;
+ goto theend;
/* For the moment there are no checks on encoding resource files to
* perform */
}
@@ -3050,7 +3050,7 @@ mch_print_begin(psettings)
{
EMSG2(_(E620: Unable to convert to print encoding \%s\),
p_encoding);
- return FALSE;
+ goto theend;
}
prt_do_conv = TRUE;
}
@@ -3063,10 +3063,10 @@ mch_print_begin(psettings)
{
EMSG2(_(E456: Can't find PostScript resource file \%s.ps\),
prt_cmap);
- return FALSE;
+ goto theend;
}
if (!prt_open_resource(res_cmap))
- return FALSE;
+ goto theend;
}
#endif
@@ -3146,9 +3146,9 @@ mch_print_begin(psettings)
{
/* Add CID font procset, and any user supplied CMap */
if (!prt_add_resource(res_cidfont))
- return FALSE;
+ goto theend;
if (prt_custom_cmap !prt_add_resource(res_cmap))
- return FALSE;
+ goto theend;
}
#endif
@@ -3158,7 +3158,7 @@ mch_print_begin(psettings)
/* There will be only one Roman font encoding to be included in the PS
* file. */
if (!prt_add_resource(res_encoding))
- return FALSE;
+ goto theend;
prt_dsc_noarg(EndProlog);
Re: [patch] memory leak in hardcopy.c
Christian wrote: Bram, there is a memory leak in hardcopy.c in the function mch_print_begin() In case of errors it returns early, without freeing the allocated memory. Attached is a patch. Thanks! -- Veni, Vidi, VW -- I came, I saw, I drove around in a little car. /// 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: [patch] fixed memory leak when doing :%!ls
Dominique wrote: I see the following memory leak in Vim-7.4.295. The leak was introduced recently in Vim-7.4.276: ==12437== 15 bytes in 3 blocks are definitely lost in loss record 28 of 349 ==12437==at 0x4C2C857: malloc (vg_replace_malloc.c:291) ==12437==by 0x4B082D: lalloc (misc2.c:921) ==12437==by 0x4B092E: alloc (misc2.c:820) ==12437==by 0x4B127B: vim_strsave (misc2.c:1245) ==12437==by 0x4ADA15: get_isolated_shell_name (misc1.c:10897) ==12437==by 0x446031: make_filter_cmd (ex_cmds.c:1559) ==12437==by 0x449275: do_bang (ex_cmds.c:1192) ==12437==by 0x45456B: ex_bang (ex_docmd.c:8776) ==12437==by 0x45E2B2: do_cmdline (ex_docmd.c:2701) ==12437==by 0x4BDF6B: nv_colon (normal.c:5308) ==12437==by 0x4C37F9: normal_cmd (normal.c:1156) ==12437==by 0x57ADA3: main_loop (main.c:1325) ==12437==by 0x57DEBB: main (main.c:1025) I can reproduce it by running: :%!ls Attached patch fixes it. Thanks! -- Send $25.00 for handy leaflet on how to make money by selling leaflets /// 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.
[patch] fixed memory leak when doing :%!ls
Hi I see the following memory leak in Vim-7.4.295. The leak was introduced recently in Vim-7.4.276: ==12437== 15 bytes in 3 blocks are definitely lost in loss record 28 of 349 ==12437==at 0x4C2C857: malloc (vg_replace_malloc.c:291) ==12437==by 0x4B082D: lalloc (misc2.c:921) ==12437==by 0x4B092E: alloc (misc2.c:820) ==12437==by 0x4B127B: vim_strsave (misc2.c:1245) ==12437==by 0x4ADA15: get_isolated_shell_name (misc1.c:10897) ==12437==by 0x446031: make_filter_cmd (ex_cmds.c:1559) ==12437==by 0x449275: do_bang (ex_cmds.c:1192) ==12437==by 0x45456B: ex_bang (ex_docmd.c:8776) ==12437==by 0x45E2B2: do_cmdline (ex_docmd.c:2701) ==12437==by 0x4BDF6B: nv_colon (normal.c:5308) ==12437==by 0x4C37F9: normal_cmd (normal.c:1156) ==12437==by 0x57ADA3: main_loop (main.c:1325) ==12437==by 0x57DEBB: main (main.c:1025) I can reproduce it by running: :%!ls Attached patch fixes it. Regards Dominique -- -- 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. diff -r 32de51778c27 src/ex_cmds.c --- a/src/ex_cmds.c Tue May 13 20:23:24 2014 +0200 +++ b/src/ex_cmds.c Tue May 13 22:49:26 2014 +0200 @@ -1554,9 +1554,11 @@ #if (defined(UNIX) !defined(ARCHIE)) || defined(OS2) int is_fish_shell; +char_u *shell_name = get_isolated_shell_name(); /* Account for fish's different syntax for subshells */ -is_fish_shell = (fnamecmp(get_isolated_shell_name(), fish) == 0); +is_fish_shell = (fnamecmp(shell_name, fish) == 0); +vim_free(shell_name); if (is_fish_shell) len = (long_u)STRLEN(cmd) + 13; /* begin; + ; end + NUL */ else
[patch] fixed memory leak when error E853 happens
Hi
Attached patch fixes a memory leak in Vim-7.4.191
whenever error E853 happens. Typing for example
the following erroneous Ex command n times will
leak n blocks:
:function Foobar(arg1, arg1)
The leak was introduced in Vim-7.3.325.
Regards
Dominique
--
--
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/groups/opt_out.
diff -r a073747c2a1e src/eval.c
--- a/src/eval.c Sun Feb 23 23:39:14 2014 +0100
+++ b/src/eval.c Mon Feb 24 00:56:20 2014 +0100
@@ -21457,6 +21457,7 @@
if (STRCMP(((char_u **)(newargs.ga_data))[i], arg) == 0)
{
EMSG2(_(E853: Duplicate argument name: %s), arg);
+ vim_free(arg);
goto erret;
}
Re: [patch] fixed memory leak when error E853 happens
Dominique wrote: Attached patch fixes a memory leak in Vim-7.4.191 whenever error E853 happens. Typing for example the following erroneous Ex command n times will leak n blocks: :function Foobar(arg1, arg1) The leak was introduced in Vim-7.3.325. Thanks, I'll include it. -- ARTHUR: Shut up! Will you shut up! DENNIS: Ah, now we see the violence inherent in the system. ARTHUR: Shut up! DENNIS: Oh! Come and see the violence inherent in the system! HELP! HELP! I'm being repressed! The Quest for the Holy Grail (Monty Python) /// 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/groups/opt_out.
Re: [PATCH] Fix memory leak in OptionsAssItem
On Sat, Dec 07, 2013 at 10:22:37AM -0800, ZyX wrote: forgive my banality, but by any chance is there an extra 's' in the subject of this email? Function was named in such a way because vim.foo objects are normally defined with Foo* functions and vim.options is named vim.options and not vim.option because it grants access to the number of options (including possibility to iterate over them if one of my recent patches is applied) and not to a single one. So there is no extra “s”. “Ass” is an abbreviation to “Assign”. Using “Ass” is a compromise between length and readability: “A” sounds like an article, “As” is a used preposition (e.g. in OptionsAsMapping), “Assi” ends with a vowel letter and is already too lengthy. No extra “s” as well. Also if you want to issue error when there is invalid assignment you could use BadAssError. -- -- 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/groups/opt_out.
Re: [PATCH] Fix memory leak in OptionsAssItem
ZyX wrote: # HG changeset patch # User ZyX kp-...@ya.ru # Date 1386410239 -14400 # Sat Dec 07 13:57:19 2013 +0400 # Branch fix-sa-warning-1 # Node ID c87415f3c0adc44106d6c2944c53f721c94cc6f5 # Parent 486655e0c5a21469364d3cf895535137f09b3724 Fix error found by @Ken Takata Thanks, I'll include it. -- How To Keep A Healthy Level Of Insanity: 11. Specify that your drive-through order is to go. /// 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/groups/opt_out.
Re: [PATCH] Fix memory leak in OptionsAssItem
On Sat, Dec 07, 2013 at 02:29:00PM +0100, Bram Moolenaar wrote: ZyX wrote: forgive my banality, but by any chance is there an extra 's' in the subject of this email? -- _|_ _ __|_|_ ._ o| |_(_)(_)|_| ||_)|| | -- -- 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/groups/opt_out.
[patch] memory leak with findfile() function
Bram,
I noticed, findfile() leaks memory.
This patch fixes it:
iff --git a/src/eval.c b/src/eval.c
--- a/src/eval.c
+++ b/src/eval.c
@@ -10491,7 +10491,7 @@
{
do
{
- if (rettv-v_type == VAR_STRING)
+ if (rettv-v_type == VAR_STRING || rettv-v_type == VAR_LIST)
vim_free(fresult);
fresult = find_file_in_path_option(first ? fname : NULL,
first ? (int)STRLEN(fname) : 0,
regards,
Christian
--
Die eine Hälfte des Lebens ist Glück, die andere ist Disziplin - und
die ist entscheidend, denn ohne Disziplin könnte man mit seinem Glück
nichts anfangen.
-- Carl Zuckmayer
--
--
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/groups/opt_out.
Re: [patch] fixed memory leak in :syntime report
Dominique Pelle wrote: Attached patch fixes a memory leak in the new command :syntime report introduced in patch 7.3.1129. I'll include it, thanks. :syntime is a great new feature. Thanks! Yep. Both for developers and syntax file writers. -- hundred-and-one symptoms of being an internet addict: 98. The Alta Vista administrators ask you what sites are missing in their index files. /// 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/groups/opt_out.
[patch] fixed memory leak in :syntime report
Hi Attached patch fixes a memory leak in the new command :syntime report introduced in patch 7.3.1129. :syntime is a great new feature. Thanks! Dominique -- -- 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/groups/opt_out. fixed-mem-leak-syntax.c-7.3.1134.patch Description: Binary data
Re: [PATCH] (3/?) More possible memory leak fixes
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1370092920 -14400
# Branch python-extended-4
# Node ID 0ee8bb6bd07f29fd51c7b753492ac727b69ac7ae
# Parent f37c4b0b09f688698e23d14c6f915968d0868523
More possible memory leak fixes
diff -r f37c4b0b09f6 -r 0ee8bb6bd07f src/if_py_both.h
--- a/src/if_py_both.h Sat Jun 01 19:52:54 2013 +0400
+++ b/src/if_py_both.h Sat Jun 01 17:22:00 2013 +0400
@@ -1017,6 +1017,7 @@
if (*key == NUL)
{
RAISE_NO_EMPTY_KEYS;
+ Py_XDECREF(todecref);
return NULL;
}
@@ -1171,6 +1172,7 @@
if (!(key = StringToChars(keyObject, todecref)))
return -1;
+
if (*key == NUL)
{
RAISE_NO_EMPTY_KEYS;
@@ -2204,9 +2206,11 @@
if (!(key = StringToChars(keyObject, todecref)))
return NULL;
+
if (*key == NUL)
{
RAISE_NO_EMPTY_KEYS;
+ Py_XDECREF(todecref);
return NULL;
}
@@ -2337,9 +2341,11 @@
if (!(key = StringToChars(keyObject, todecref)))
return -1;
+
if (*key == NUL)
{
RAISE_NO_EMPTY_KEYS;
+ Py_XDECREF(todecref);
return -1;
}
@@ -4556,6 +4562,7 @@
dict_unref(dict);
return -1;
}
+
if (*key == NUL)
{
dict_unref(dict);
@@ -4639,6 +4646,7 @@
dict_unref(dict);
return -1;
}
+
if (*key == NUL)
{
Py_DECREF(keyObject);
--
--
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/groups/opt_out.
*** /tmp/extdiff.MqxLOH/vim.f37c4b0b09f6/src/if_py_both.h 2013-06-01 20:12:35.611342481 +0400
--- vim.0ee8bb6bd07f/src/if_py_both.h 2013-06-01 20:12:35.620342392 +0400
***
*** 1017,1022
--- 1017,1023
if (*key == NUL)
{
RAISE_NO_EMPTY_KEYS;
+ Py_XDECREF(todecref);
return NULL;
}
***
*** 1171,1176
--- 1172,1178
if (!(key = StringToChars(keyObject, todecref)))
return -1;
+
if (*key == NUL)
{
RAISE_NO_EMPTY_KEYS;
***
*** 2204,2212
--- 2206,2216
if (!(key = StringToChars(keyObject, todecref)))
return NULL;
+
if (*key == NUL)
{
RAISE_NO_EMPTY_KEYS;
+ Py_XDECREF(todecref);
return NULL;
}
***
*** 2337,2345
--- 2341,2351
if (!(key = StringToChars(keyObject, todecref)))
return -1;
+
if (*key == NUL)
{
RAISE_NO_EMPTY_KEYS;
+ Py_XDECREF(todecref);
return -1;
}
***
*** 4556,4561
--- 4562,4568
dict_unref(dict);
return -1;
}
+
if (*key == NUL)
{
dict_unref(dict);
***
*** 4639,4644
--- 4646,4652
dict_unref(dict);
return -1;
}
+
if (*key == NUL)
{
Py_DECREF(keyObject);
Re: [PATCH] (15/?) More possible memory leak fixes and error checking
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1369520053 -14400
# Node ID 484d93ca3c0244e847c101b6f550f8b8c94ae6f6
# Parent 72a773f3fc682f63c79d1b8481626fdec3198ddd
More possible memory leak fixes and error checking
diff -r 72a773f3fc68 -r 484d93ca3c02 src/eval.c
--- a/src/eval.cSat May 25 22:40:17 2013 +0400
+++ b/src/eval.cSun May 26 02:14:13 2013 +0400
@@ -412,7 +412,6 @@
static int get_lit_string_tv __ARGS((char_u **arg, typval_T *rettv, int
evaluate));
static int get_list_tv __ARGS((char_u **arg, typval_T *rettv, int evaluate));
static int rettv_list_alloc __ARGS((typval_T *rettv));
-static void listitem_free __ARGS((listitem_T *item));
static long list_len __ARGS((list_T *l));
static int list_equal __ARGS((list_T *l1, list_T *l2, int ic, int recursive));
static int dict_equal __ARGS((dict_T *d1, dict_T *d2, int ic, int recursive));
@@ -428,7 +427,6 @@
static int list_join __ARGS((garray_T *gap, list_T *l, char_u *sep, int echo,
int copyID));
static int free_unref_items __ARGS((int copyID));
static int rettv_dict_alloc __ARGS((typval_T *rettv));
-static void dict_free __ARGS((dict_T *d, int recurse));
static dictitem_T *dictitem_copy __ARGS((dictitem_T *org));
static void dictitem_remove __ARGS((dict_T *dict, dictitem_T *item));
static dict_T *dict_copy __ARGS((dict_T *orig, int deep, int copyID));
@@ -5955,7 +5953,7 @@
/*
* Free a list item. Also clears the value. Does not notify watchers.
*/
-static void
+void
listitem_free(item)
listitem_T *item;
{
@@ -7031,7 +7029,7 @@
* Free a Dictionary, including all items it contains.
* Ignores the reference count.
*/
-static void
+void
dict_free(d, recurse)
dict_T *d;
intrecurse;/* Free Lists and Dictionaries recursively. */
diff -r 72a773f3fc68 -r 484d93ca3c02 src/if_py_both.h
--- a/src/if_py_both.h Sat May 25 22:40:17 2013 +0400
+++ b/src/if_py_both.h Sun May 26 02:14:13 2013 +0400
@@ -32,8 +32,15 @@
#define DICTKEY_DECL \
PyObject *dictkey_todecref;
+#define DICTKEY_CHECK_EMPTY(err) \
+if (*key == NUL) \
+{ \
+ PyErr_SetString(PyExc_ValueError, _(empty keys are not allowed)); \
+ return err; \
+}
+#define DICTKEY_SET_KEY (key = StringToChars(keyObject, dictkey_todecref))
#define DICTKEY_GET(err, decref) \
-if (!(key = StringToChars(keyObject, dictkey_todecref))) \
+if (!DICTKEY_SET_KEY) \
{ \
if (decref) \
{ \
@@ -43,11 +50,7 @@
} \
if (decref !dictkey_todecref) \
dictkey_todecref = keyObject; \
-if (*key == NUL) \
-{ \
- PyErr_SetString(PyExc_ValueError, _(empty keys are not allowed)); \
- return err; \
-}
+DICTKEY_CHECK_EMPTY(err)
#define DICTKEY_UNREF \
Py_XDECREF(dictkey_todecref);
@@ -651,9 +654,13 @@
/* Convert the Vim type into a Python type. Create a dictionary that's
* used to check for recursive loops. */
-lookup_dict = PyDict_New();
-result = VimToPython(our_tv, 1, lookup_dict);
-Py_DECREF(lookup_dict);
+if (!(lookup_dict = PyDict_New()))
+ result = NULL;
+else
+{
+ result = VimToPython(our_tv, 1, lookup_dict);
+ Py_DECREF(lookup_dict);
+}
Py_BEGIN_ALLOW_THREADS
@@ -1401,7 +1408,9 @@
return NULL;
}
-lookup_dict = PyDict_New();
+if (!(lookup_dict = PyDict_New()))
+ return NULL;
+
if (list_py_concat(l, obj, lookup_dict) == -1)
{
Py_DECREF(lookup_dict);
@@ -4022,12 +4031,8 @@
PyObject *valObject;
Py_ssize_t iter = 0;
-dict = dict_alloc();
-if (dict == NULL)
-{
- PyErr_NoMemory();
+if (!(dict = py_dict_alloc()))
return -1;
-}
tv-v_type = VAR_DICT;
tv-vval.v_dict = dict;
@@ -4037,9 +4042,17 @@
DICTKEY_DECL
if (keyObject == NULL || valObject == NULL)
+ {
+ dict_unref(dict);
return -1;
-
- DICTKEY_GET(-1, 0)
+ }
+
+ if (!DICTKEY_SET_KEY)
+ {
+ dict_unref(dict);
+ return -1;
+ }
+ DICTKEY_CHECK_EMPTY(-1)
di = dictitem_alloc(key);
@@ -4048,6 +4061,7 @@
if (di == NULL)
{
PyErr_NoMemory();
+ dict_unref(dict);
return -1;
}
di-di_tv.v_lock = 0;
@@ -4055,6 +4069,7 @@
if (_ConvertFromPyObject(valObject, di-di_tv, lookup_dict) == -1)
{
vim_free(di);
+ dict_unref(dict);
return -1;
}
@@ -4062,10 +4077,13 @@
{
clear_tv(di-di_tv);
vim_free(di);
+ dict_unref(dict);
PyErr_SetVim(_(failed to add key to dictionary));
return -1;
}
}
+
+--dict-dv_refcount;
return 0;
}
@@ -4081,19 +4099,18 @@
PyObject *valObject;
Py_ssize_t lsize;
-dict = dict_alloc();
-if (dict == NULL)
+if (!(dict = py_dict_alloc()))
+ return -1
[patch] fixed memory leak in regexp_nfa.c in Vim-7.3.988
Hi Attached patch fixes a memory leak in regexp_nfa.c detected by valgrind: ==3055== 128 bytes in 4 blocks are definitely lost in loss record 76 of 110 ==3055==at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3055==by 0x50E98C: lalloc (misc2.c:929) ==3055==by 0x572226: post2nfa (regexp_nfa.c:2161) ==3055==by 0x57697F: nfa_regcomp (regexp_nfa.c:3682) ==3055==by 0x576CF7: vim_regcomp (regexp.c:7827) ==3055==by 0x5C6829: get_syn_pattern (syntax.c:5606) ==3055==by 0x5C56E0: syn_cmd_region (syntax.c:5109) ==3055==by 0x5C7CCB: ex_syntax (syntax.c:6218) ==3055==by 0x49A0E6: do_one_cmd (ex_docmd.c:2686) ==3055==by 0x49764B: do_cmdline (ex_docmd.c:1124) ==3055==by 0x495318: do_source (ex_cmds2.c:3260) ==3055==by 0x494516: source_callback (ex_cmds2.c:2687) ==3055==by 0x494717: do_in_runtimepath (ex_cmds2.c:2781) ==3055==by 0x494540: source_runtime (ex_cmds2.c:2701) ==3055==by 0x4944EE: ex_runtime (ex_cmds2.c:2677) ==3055==by 0x49A0E6: do_one_cmd (ex_docmd.c:2686) ==3055==by 0x49764B: do_cmdline (ex_docmd.c:1124) ==3055==by 0x47B484: ex_execute (eval.c:20914) ==3055==by 0x49A0E6: do_one_cmd (ex_docmd.c:2686) ==3055==by 0x49764B: do_cmdline (ex_docmd.c:1124) ==3055==by 0x47F99D: call_user_func (eval.c:22651) ==3055==by 0x467941: call_func (eval.c:8494) ==3055==by 0x4674F6: get_func_tv (eval.c:8336) ==3055==by 0x45FEC4: ex_call (eval.c:3459) ==3055==by 0x49A0E6: do_one_cmd (ex_docmd.c:2686) ==3055==by 0x49764B: do_cmdline (ex_docmd.c:1124) ==3055==by 0x4C6547: apply_autocmds_group (fileio.c:9453) ==3055==by 0x4C5D39: apply_autocmds (fileio.c:9032) ==3055==by 0x5442A2: did_set_string_option (option.c:7067) ==3055==by 0x53FD57: do_set (option.c:4872) ==3055==by 0x4A8C5F: ex_set (ex_docmd.c:11349) ==3055==by 0x49A0E6: do_one_cmd (ex_docmd.c:2686) ==3055==by 0x49764B: do_cmdline (ex_docmd.c:1124) ==3055==by 0x47B484: ex_execute (eval.c:20914) ==3055==by 0x49A0E6: do_one_cmd (ex_docmd.c:2686) ==3055==by 0x49764B: do_cmdline (ex_docmd.c:1124) ==3055==by 0x4C6547: apply_autocmds_group (fileio.c:9453) ==3055==by 0x4C5D39: apply_autocmds (fileio.c:9032) ==3055==by 0x5442FC: did_set_string_option (option.c:7075) ==3055==by 0x541274: set_string_option (option.c:5627) ==3055==by 0x547673: set_option_value (option.c:8999) ==3055==by 0x4A8BBA: ex_setfiletype (ex_docmd.c:11316) ==3055==by 0x49A0E6: do_one_cmd (ex_docmd.c:2686) ==3055==by 0x49764B: do_cmdline (ex_docmd.c:1124) ==3055==by 0x47F99D: call_user_func (eval.c:22651) ==3055==by 0x467941: call_func (eval.c:8494) ==3055==by 0x4674F6: get_func_tv (eval.c:8336) ==3055==by 0x45FEC4: ex_call (eval.c:3459) ==3055==by 0x49A0E6: do_one_cmd (ex_docmd.c:2686) ==3055==by 0x49764B: do_cmdline (ex_docmd.c:1124) I can reproduce it with Vim-7.3.988 using... vim -N -c ':syntax on' vim/src/spell.c ... and then exiting immediately with :q! Regards Dominique -- -- 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/groups/opt_out. fix-leak-regex_nfa.c-7.3.988.patch Description: Binary data
Re: [patch] fixed memory leak in regexp_nfa.c in Vim-7.3.988
Dominique Pelle wrote: Attached patch fixes a memory leak in regexp_nfa.c detected by valgrind: ==3055== 128 bytes in 4 blocks are definitely lost in loss record 76 of 110 ==3055==at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3055==by 0x50E98C: lalloc (misc2.c:929) ==3055==by 0x572226: post2nfa (regexp_nfa.c:2161) ==3055==by 0x57697F: nfa_regcomp (regexp_nfa.c:3682) ==3055==by 0x576CF7: vim_regcomp (regexp.c:7827) [...] I can reproduce it with Vim-7.3.988 using... vim -N -c ':syntax on' vim/src/spell.c ... and then exiting immediately with :q! Thanks! Please keep an eye out for more leaks. The more problems I find in the NFA code the less I trust it... -- The most powerful force in the universe is gossip. /// 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/groups/opt_out.
Re: [patch] fixed memory leak in regexp_nfa.c in Vim-7.3.988
On Tuesday, May 21, 2013 9:27:34 AM UTC-5, Bram Moolenaar wrote: Dominique Pelle wrote: Attached patch fixes a memory leak in regexp_nfa.c detected by valgrind: ==3055== 128 bytes in 4 blocks are definitely lost in loss record 76 of 110 ==3055==at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3055==by 0x50E98C: lalloc (misc2.c:929) ==3055==by 0x572226: post2nfa (regexp_nfa.c:2161) ==3055==by 0x57697F: nfa_regcomp (regexp_nfa.c:3682) ==3055==by 0x576CF7: vim_regcomp (regexp.c:7827) [...] I can reproduce it with Vim-7.3.988 using... vim -N -c ':syntax on' vim/src/spell.c ... and then exiting immediately with :q! Thanks! Please keep an eye out for more leaks. The more problems I find in the NFA code the less I trust it... Maybe you could ask the Coverity folks to run a new analysis on this code. I know in tested and proven code it finds mostly stuff you don't care about, but in new code it may be more useful. I'm not sure how they handle their open-source scan project. -- -- 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/groups/opt_out.
Re: [patch] fixed memory leak in regexp_nfa.c in Vim-7.3.988
Dominique Pelle wrote: Attached patch fixes a memory leak in regexp_nfa.c detected by valgrind: ==3055== 128 bytes in 4 blocks are definitely lost in loss record 76 of 110 ==3055==at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3055==by 0x50E98C: lalloc (misc2.c:929) ==3055==by 0x572226: post2nfa (regexp_nfa.c:2161) ==3055==by 0x57697F: nfa_regcomp (regexp_nfa.c:3682) ==3055==by 0x576CF7: vim_regcomp (regexp.c:7827) [...] I can reproduce it with Vim-7.3.988 using... vim -N -c ':syntax on' vim/src/spell.c ... and then exiting immediately with :q! Thanks! Please keep an eye out for more leaks. The more problems I find in the NFA code the less I trust it... I won't find time to test much before next Sunday as I am traveling. I also want to sent updates of the French Esperanto translations early next week. Hopefully that's early enough for the 7.4 release. The deadline for normal runtime file updates is end of May. After that it's bug fixing only. -- Computers make very fast, very accurate, mistakes. /// 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/groups/opt_out.
Re: [PATCH(3/3)] .locked and .scope attributes, refactoring and memory leak fix
Hm, Mercurial produces unified diffs (preferably in git format) with some stuff (optionally including a commit message) added in what man patch calls the leading garbage, and Bram usually publishes patches as non-unified context diffs on the FTP site and by email, but wasn't sending both formats (unified inline, concatenating three Mercurial patches, each with its own leading garbage; and non-unified as attachment) a little overkill? I would have sent, as attachment, the patches in one if these formats but not both, and with a .diff extension (not .cdiff) so Thunderbird or SeaMonkey (and possibly some other mailers) would display the attachments inline. Bram said context diffs should be used because some users may be unable to use them. I say context diffs are hard to read. Hence you see two diffs here: one created with “hg export”, one with “hg extdiff” (well, really a custom command). If you like some other diff (even side-by-side), you can clone/pull from my vim repository: https://bitbucket.org/ZyX_I/vim. I find this way of distributing patches much more convenient then any kind of diffs send by anybody here. -- 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: [PATCH(3/3)] .locked and .scope attributes, refactoring and memory leak fix
Zyx wrote: Fixed memory leak in case of some exceptions For such a big patch you could spend a little time on describing what problem it fixes and how it fixes it. Otherwise my patch description might be missing the point. -- WOMAN: King of the who? ARTHUR: The Britons. WOMAN: Who are the Britons? ARTHUR: Well, we all are. we're all Britons and I am your king. The Quest for the Holy Grail (Monty Python) /// 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
Re: [PATCH(3/3)] .locked and .scope attributes, refactoring and memory leak fix
воскресенье, 9 сентября 2012 г., 18:17:48 UTC+4 пользователь Bram Moolenaar написал: For such a big patch you could spend a little time on describing what problem it fixes and how it fixes it. Otherwise my patch description might be missing the point. Agreed, thats why I've added forgotten descriptions to all three patches in the second message: First adds some missing DICTKEY_UNREF before returning from function in case of exception. In the original message it is 1.cdiff file or first 43 lines of the message body. -- 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: [PATCH(3/3)] .locked and .scope attributes, refactoring and memory leak fix
Forgot descriptions: First adds some missing DICTKEY_UNREF before returning from function in case of exception. Second moves code from if_python*.c to if_py_both.h Third adds .locked and .scope attributes: they should be used in case you prefer to check for possible errors before running something instead of catching an exception. Assigning to .locked attribute enables you to lock/unlock lists and dictionaries from python. -- 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: [PATCH(3/3)] .locked and .scope attributes, refactoring and memory leak fix
On 09/09/12 03:11, ZyX wrote: Forgot descriptions: First adds some missing DICTKEY_UNREF before returning from function in case of exception. Second moves code from if_python*.c to if_py_both.h Third adds .locked and .scope attributes: they should be used in case you prefer to check for possible errors before running something instead of catching an exception. Assigning to .locked attribute enables you to lock/unlock lists and dictionaries from python. Hm, Mercurial produces unified diffs (preferably in git format) with some stuff (optionally including a commit message) added in what man patch calls the leading garbage, and Bram usually publishes patches as non-unified context diffs on the FTP site and by email, but wasn't sending both formats (unified inline, concatenating three Mercurial patches, each with its own leading garbage; and non-unified as attachment) a little overkill? I would have sent, as attachment, the patches in one if these formats but not both, and with a .diff extension (not .cdiff) so Thunderbird or SeaMonkey (and possibly some other mailers) would display the attachments inline. Best regards, Tony. -- DENNIS: Listen -- strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. The Quest for the Holy Grail (Monty Python) -- 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: [patch] fixed memory leak when writing undo file with ACL
Dominique Pelle wrote: The following command shows a memory leak when writing the undo file with ACL in Vim-7.3.531 (Linux x86). $ valgrind --leak-check=yes ./vim -u NONE \ -c 'set undofile undodir=/tmp|e /tmp/foo|w!|w!|q!' Each write to file leaks one block. Above example writes twice so it leaks 2 blocks: ==2765== 272 (56 direct, 216 indirect) bytes in 2 blocks are definitely lost in loss record 129 of 162 ==2765==at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2765==by 0x493720A: ??? (in /lib/i386-linux-gnu/libacl.so.1.1.0) ==2765==by 0x814D202: mch_get_acl (os_unix.c:2747) ==2765==by 0x81C51E2: u_write_undo (undo.c:1536) ==2765==by 0x80CD931: buf_write (fileio.c:5084) ==2765==by 0x8099D1B: do_write (ex_cmds.c:2692) ==2765==by 0x80997D7: ex_write (ex_cmds.c:2501) ==2765==by 0x80AADD1: do_one_cmd (ex_docmd.c:2668) ==2765==by 0x80A8699: do_cmdline (ex_docmd.c:1122) ==2765==by 0x80A7D6D: do_cmdline_cmd (ex_docmd.c:727) ==2765==by 0x81F5C93: exe_commands (main.c:2842) ==2765==by 0x81F332A: main (main.c:909) Attached patch fixes it. Thanks! -- hundred-and-one symptoms of being an internet addict: 9. All your daydreaming is preoccupied with getting a faster connection to the net: 28.8...ISDN...cable modem...T1...T3. /// 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
[patch] fixed memory leak when writing undo file with ACL
Hi The following command shows a memory leak when writing the undo file with ACL in Vim-7.3.531 (Linux x86). $ valgrind --leak-check=yes ./vim -u NONE \ -c 'set undofile undodir=/tmp|e /tmp/foo|w!|w!|q!' Each write to file leaks one block. Above example writes twice so it leaks 2 blocks: ==2765== 272 (56 direct, 216 indirect) bytes in 2 blocks are definitely lost in loss record 129 of 162 ==2765==at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2765==by 0x493720A: ??? (in /lib/i386-linux-gnu/libacl.so.1.1.0) ==2765==by 0x814D202: mch_get_acl (os_unix.c:2747) ==2765==by 0x81C51E2: u_write_undo (undo.c:1536) ==2765==by 0x80CD931: buf_write (fileio.c:5084) ==2765==by 0x8099D1B: do_write (ex_cmds.c:2692) ==2765==by 0x80997D7: ex_write (ex_cmds.c:2501) ==2765==by 0x80AADD1: do_one_cmd (ex_docmd.c:2668) ==2765==by 0x80A8699: do_cmdline (ex_docmd.c:1122) ==2765==by 0x80A7D6D: do_cmdline_cmd (ex_docmd.c:727) ==2765==by 0x81F5C93: exe_commands (main.c:2842) ==2765==by 0x81F332A: main (main.c:909) Attached patch fixes it. Regards -- Dominique -- 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 fix-leak-acl-undo.c-7.3.531.patch Description: Binary data
Re: [patch] fixed memory leak in :rviminfo! when reading dict or list global variables
Dominique Pelle wrote:
Using Vim-7.3.475, I can reproduce a memory leak using
the ':rv!' command when reading dictionary or list global
variables i.e. with 'viminfo' containing ! (:help viminfo-!).
Steps to reproduce:
$ cat leak.vim EOF
set nocp
set viminfo+=!
let FOO=[]
let BAR={'bar':1}
wv! /tmp/foobar
rv! /tmp/foobar
rv! /tmp/foobar
rv! /tmp/foobar
EOF
$ valgrind --leak-check=yes --log-file=vg.log vim -u NONE -S leak.vim
Then exit Vim with :q and notice that log file vg.log contains the
following leak:
==17285== 96 bytes in 6 blocks are definitely lost in loss record 70 of 95
==17285==at 0x4C241C3: malloc (vg_replace_malloc.c:195)
==17285==by 0x4D8AF9: lalloc (misc2.c:928)
==17285==by 0x4D8A18: alloc (misc2.c:827)
==17285==by 0x432D8D: eval_expr (eval.c:1548)
==17285==by 0x4542A9: read_viminfo_varlist (eval.c:22964)
==17285==by 0x458BC6: read_viminfo_up_to_marks (ex_cmds.c:2134)
==17285==by 0x4589FE: do_viminfo (ex_cmds.c:2053)
==17285==by 0x458444: read_viminfo (ex_cmds.c:1710)
==17285==by 0x478E3D: ex_viminfo (ex_docmd.c:11010)
==17285==by 0x46B583: do_one_cmd (ex_docmd.c:2668)
==17285==by 0x468D24: do_cmdline (ex_docmd.c:1122)
==17285==by 0x466BD1: do_source (ex_cmds2.c:3188)
The number of blocks leaked (6) corresponds to the number
of 'rv! /tmp/foo' commands in script (3) times the number of
list and dictionary variables being read in viminfo file (2 in this
example for FOO and BAR).
Attached patch fixes the leak.
Thanks! I'll include it soon.
--
hundred-and-one symptoms of being an internet addict:
212. Your Internet group window has more icons than your Accessories window.
/// 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
[patch] fixed memory leak in :rviminfo! when reading dict or list global variables
Hi
Using Vim-7.3.475, I can reproduce a memory leak using
the ':rv!' command when reading dictionary or list global
variables i.e. with 'viminfo' containing ! (:help viminfo-!).
Steps to reproduce:
$ cat leak.vim EOF
set nocp
set viminfo+=!
let FOO=[]
let BAR={'bar':1}
wv! /tmp/foobar
rv! /tmp/foobar
rv! /tmp/foobar
rv! /tmp/foobar
EOF
$ valgrind --leak-check=yes --log-file=vg.log vim -u NONE -S leak.vim
Then exit Vim with :q and notice that log file vg.log contains the
following leak:
==17285== 96 bytes in 6 blocks are definitely lost in loss record 70 of 95
==17285==at 0x4C241C3: malloc (vg_replace_malloc.c:195)
==17285==by 0x4D8AF9: lalloc (misc2.c:928)
==17285==by 0x4D8A18: alloc (misc2.c:827)
==17285==by 0x432D8D: eval_expr (eval.c:1548)
==17285==by 0x4542A9: read_viminfo_varlist (eval.c:22964)
==17285==by 0x458BC6: read_viminfo_up_to_marks (ex_cmds.c:2134)
==17285==by 0x4589FE: do_viminfo (ex_cmds.c:2053)
==17285==by 0x458444: read_viminfo (ex_cmds.c:1710)
==17285==by 0x478E3D: ex_viminfo (ex_docmd.c:11010)
==17285==by 0x46B583: do_one_cmd (ex_docmd.c:2668)
==17285==by 0x468D24: do_cmdline (ex_docmd.c:1122)
==17285==by 0x466BD1: do_source (ex_cmds2.c:3188)
The number of blocks leaked (6) corresponds to the number
of 'rv! /tmp/foo' commands in script (3) times the number of
list and dictionary variables being read in viminfo file (2 in this
example for FOO and BAR).
Attached patch fixes the leak.
Regards
-- Dominique
--
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
diff -r 74686ae0b181 src/eval.c
--- a/src/eval.c Fri Mar 16 20:16:46 2012 +0100
+++ b/src/eval.c Sat Mar 17 18:28:31 2012 +0100
@@ -22971,6 +22971,7 @@
{
vim_free(tv.vval.v_string);
tv = *etv;
+ vim_free(etv);
}
}
Re: [patch] fixed memory leak in :find CTRL-D
Dominique Pelle wrote: I see a memory leak in Vim-7.3b BETA (2376:878562053ba3) when doing :find CTRL-D ==5706== 88 bytes in 2 blocks are definitely lost in loss record 92 of 117 ==5706==at 0x4024F70: malloc (vg_replace_malloc.c:236) ==5706==by 0x813778A: lalloc (misc2.c:920) ==5706==by 0x817C667: vim_regcomp (regexp.c:1063) ==5706==by 0x8135A9F: uniquefy_paths (misc1.c:9370) ==5706==by 0x8135FB8: gen_expand_wildcards (misc1.c:9587) ==5706==by 0x8134F6F: expand_wildcards (misc1.c:8568) ==5706==by 0x8134F1E: expand_wildcards_eval (misc1.c:8539) ==5706==by 0x80DF179: ExpandFromContext (ex_getln.c:4464) ==5706==by 0x80DEE62: expand_cmdline (ex_getln.c:4356) ==5706==by 0x80DE33A: showmatches (ex_getln.c:3858) ==5706==by 0x80DA4D3: getcmdline (ex_getln.c:1167) ==5706==by 0x80DBA38: getexline (ex_getln.c:2129) ==5706==by 0x80C5EAD: do_cmdline (ex_docmd.c:1018) ==5706==by 0x814DDE9: nv_colon (normal.c:5295) ==5706==by 0x814751F: normal_cmd (normal.c:1188) ==5706==by 0x8108F38: main_loop (main.c:1256) ==5706==by 0x810898F: main (main.c:964) Fixed in attached patch. Thanks! -- Every person is responsible for the choices he makes. /// 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
[patch] fixed memory leak in :find CTRL-D
Hi
I see a memory leak in Vim-7.3b BETA (2376:878562053ba3)
when doing :find CTRL-D
==5706== 88 bytes in 2 blocks are definitely lost in loss record 92 of 117
==5706==at 0x4024F70: malloc (vg_replace_malloc.c:236)
==5706==by 0x813778A: lalloc (misc2.c:920)
==5706==by 0x817C667: vim_regcomp (regexp.c:1063)
==5706==by 0x8135A9F: uniquefy_paths (misc1.c:9370)
==5706==by 0x8135FB8: gen_expand_wildcards (misc1.c:9587)
==5706==by 0x8134F6F: expand_wildcards (misc1.c:8568)
==5706==by 0x8134F1E: expand_wildcards_eval (misc1.c:8539)
==5706==by 0x80DF179: ExpandFromContext (ex_getln.c:4464)
==5706==by 0x80DEE62: expand_cmdline (ex_getln.c:4356)
==5706==by 0x80DE33A: showmatches (ex_getln.c:3858)
==5706==by 0x80DA4D3: getcmdline (ex_getln.c:1167)
==5706==by 0x80DBA38: getexline (ex_getln.c:2129)
==5706==by 0x80C5EAD: do_cmdline (ex_docmd.c:1018)
==5706==by 0x814DDE9: nv_colon (normal.c:5295)
==5706==by 0x814751F: normal_cmd (normal.c:1188)
==5706==by 0x8108F38: main_loop (main.c:1256)
==5706==by 0x810898F: main (main.c:964)
Fixed in attached patch.
-- Dominique
--
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
diff -r 878562053ba3 src/misc1.c
--- a/src/misc1.c Thu Jul 22 22:30:23 2010 +0200
+++ b/src/misc1.c Thu Jul 22 23:47:35 2010 +0200
@@ -9306,7 +9306,7 @@
}
/*
- * Remove adjecent duplicate entries from gap, which is a list of file names
+ * Remove adjacent duplicate entries from gap, which is a list of file names
* in allocated memory.
*/
static void
@@ -9354,7 +9354,7 @@
/*
* We need to prepend a '*' at the beginning of file_pattern so that the
* regex matches anywhere in the path. FIXME: is this valid for all
- * possible pattern?
+ * possible patterns?
*/
len = (int)STRLEN(pattern);
file_pattern = alloc(len + 2);
@@ -9391,6 +9391,7 @@
}
}
+vim_free(regmatch.regprog);
if (sort_again)
{
sort_strings(fnames, gap-ga_len);
Re: [patch] fixed memory leak in :find CTRL-D
2010/7/23 Dominique Pellé dominique.pe...@gmail.com: Hi I see a memory leak in Vim-7.3b BETA (2376:878562053ba3) when doing :find CTRL-D I knew you would! Fixed in attached patch. -- Dominique Thanks for fixing my leak :) btw, I'm still working on fixing the issues mentioned in [1] that is related to the find/sfind/tabfind completion. nazri. [1] http://article.gmane.org/gmane.editors.vim.devel/27120 -- 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
Memory leak
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 Compiled by mi...@debian Normal version without GUI. Features included (+) or not (-): -arabic +autocmd -balloon_eval -browse +builtin_terms +byte_offset +cindent -clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv -cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path +find_in_path +float +folding -footer +fork() -gettext -hangul_input -iconv +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse -mouseshape -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse +mouse_xterm -multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra -perl +postscript +printer -profile -python +quickfix +reltime -rightleft -ruby +scrollbind -signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc fall-back for $VIM: /usr/local/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 Linking: gcc -L/usr/local/lib -o vim -lm -lncurses -- 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
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: [patch] fixed memory leak (unlikely to happen)
Dominique Pelle wrote:
Following code in src/normal.c is wrong, since it calls 'vim_free(buf)'
which does nothing since it's inside 'if (buf == NULL)':
src/normal.c:
!!5565 buf = (char_u *)vim_realloc(buf, STRLEN(buf) + STRLEN(p) + 1);
!!5566 if (buf == NULL)
5567 {
!!5568 vim_free(buf);
5569 vim_free(p);
5570 return;
5571 }
Although unlikely to happen, it leaks memory since realloc() does
not free 'buf' if it fails.
Attached patch fixes it.
Thanks, I'll include it.
--
GALAHAD: No look, really, this isn't nescess ...
PIGLET: We must examine you.
GALAHAD: There's nothing wrong with ... that.
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// 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
[patch] fixed memory leak (unlikely to happen)
Hi
Following code in src/normal.c is wrong, since it calls 'vim_free(buf)'
which does nothing since it's inside 'if (buf == NULL)':
src/normal.c:
!!5565 buf = (char_u *)vim_realloc(buf, STRLEN(buf) + STRLEN(p) + 1);
!!5566 if (buf == NULL)
5567 {
!!5568 vim_free(buf);
5569 vim_free(p);
5570 return;
5571 }
Although unlikely to happen, it leaks memory since realloc() does
not free 'buf' if it fails.
Attached patch fixes it.
Regards
-- Dominique
--
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
diff -r 3331756e4232 src/normal.c
--- a/src/normal.c Thu Jul 08 22:27:55 2010 +0200
+++ b/src/normal.c Thu Jul 08 22:39:02 2010 +0200
@@ -5410,6 +5410,7 @@
{
char_u *ptr = NULL;
char_u *buf;
+char_u *realloc_buf;
char_u *p;
char_u *kp; /* value of 'keywordprg' */
int kp_help; /* 'keywordprg' is :help */
@@ -5562,13 +5563,14 @@
vim_free(buf);
return;
}
- buf = (char_u *)vim_realloc(buf, STRLEN(buf) + STRLEN(p) + 1);
- if (buf == NULL)
+ realloc_buf = (char_u *)vim_realloc(buf, STRLEN(buf) + STRLEN(p) + 1);
+ if (realloc_buf == NULL)
{
vim_free(buf);
vim_free(p);
return;
}
+ buf = realloc_buf;
STRCAT(buf, p);
vim_free(p);
}
Memory leak
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
Compiled by james...@debian.org
Huge version with GTK2 GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl
+cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape
+dialog_con_gui +diff +digraphs +dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+folding -footer +fork() +gettext
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
+linebreak +lispindent +listcmds +localmap
+menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm
-mouse_jsbterm +mouse_netterm +mouse_xterm
+multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl
+postscript +printer +profile +python
+quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff
+statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white +tcl +terminfo +termresponse
+textobjects +title +toolbar +user_commands
+vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore
+wildmenu +windows +writebackup +X11
-xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: $VIM/vimrc
user vimrc file: $HOME/.vimrc
user exrc file: $HOME/.exrc
system gvimrc file: $VIM/gvimrc
user gvimrc file: $HOME/.gvimrc
system menu file: $VIMRUNTIME/menu.vim
fall-back for $VIM: /usr/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/
usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1
-g
-O2 -O2 -g -Wall-D_REENTRANT -D_
GNU_SOURCE -DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.10/CORE -I/u
sr/include/python2.5 -pthread -I/usr/include/tcl8.4 -D_REENTRANT=1
-D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1 -I/us
r/lib/ruby/1.8/i486-linux
Linking: gcc -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,--as-needed
-L/usr/local/lib -o vim -lgtk-x11-2.0 -l
gdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0
-lXt -lncurses -lselinux -lacl -lgpm -Wl,-E -L/usr/local/lib
-L/usr/lib/perl/5.10/CORE -lperl -L/usr/lib/python2.5
/config -lpython2.5 -lutil -Xlinker -export-dynamic -Wl,-O1
-Wl,-Bsymbolic-functions -L/usr/lib -ltcl8.4 -lieee -lrub
y1.8 -lm
--
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
Memory leak
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 Compiled by james...@debian.org Huge version with GTK2 GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /usr/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/ usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -g -O2 -O2 -g -Wall-D_REENTRANT -D_ GNU_SOURCE -DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.10/CORE -I/u sr/include/python2.5 -pthread -I/usr/include/tcl8.4 -D_REENTRANT=1 -D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1 -I/us r/lib/ruby/1.8/i486-linux Linking: gcc -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,--as-needed -L/usr/local/lib -o vim -lgtk-x11-2.0 -l gdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lncurses -lselinux -lacl -lgpm -Wl,-E -L/usr/local/lib -L/usr/lib/perl/5.10/CORE -lperl -L/usr/lib/python2.5 /config -lpython2.5 -lutil -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/lib -ltcl8.4 -lieee -lrub y1.8 -lm -- 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: [patch] fixed memory leak when encrypting buffer several times
Dominique Pelle wrote: The following script reproduces a memory leak which happens when encrypting a buffer several times with different keys: $ cat leak.vim for i in range(1, 5) call feedkeys(:X\CRfoo\CRfoo\CR) call feedkeys(:X\CRbar\CRbar\CR) endfor $ rm /tmp/foo; valgrind --leak-check=yes vim -u NONE /tmo/foo -S leak.vim ==3281== 84 bytes in 1 blocks are definitely lost in loss record 89 of 114 ==3281==at 0x4024F70: malloc (vg_replace_malloc.c:236) ==3281==by 0x8115FEE: lalloc (misc2.c:920) ==3281==by 0x8115EDE: alloc (misc2.c:818) ==3281==by 0x80FB52A: ml_add_stack (memline.c:3800) ==3281==by 0x80FB289: ml_find_line (memline.c:3704) ==3281==by 0x80F9329: ml_get_buf (memline.c:2474) ==3281==by 0x80F91C5: ml_get (memline.c:2390) ==3281==by 0x805AE20: chk_modeline (buffer.c:4881) ==3281==by 0x805AD7C: do_modelines (buffer.c:4846) ==3281==by 0x805369B: open_buffer (buffer.c:263) ==3281==by 0x80E9B4F: create_windows (main.c:2545) ==3281==by 0x80E7613: main (main.c:804) - this leak happens only once ==3281== 756 bytes in 9 blocks are definitely lost in loss record 101 of 114 ==3281==at 0x4024F70: malloc (vg_replace_malloc.c:236) ==3281==by 0x8115FEE: lalloc (misc2.c:920) ==3281==by 0x8115EDE: alloc (misc2.c:818) ==3281==by 0x80FB52A: ml_add_stack (memline.c:3800) ==3281==by 0x80F5EA1: ml_set_crypt_key (memline.c:547) ==3281==by 0x8142452: did_set_string_option (option.c:5983) ==3281==by 0x81416F0: set_string_option (option.c:5514) ==3281==by 0x814684B: set_option_value (option.c:8532) ==3281==by 0x8119429: get_crypt_key (misc2.c:3943) ==3281==by 0x80B484E: ex_X (ex_docmd.c:11165) ==3281==by 0x80A797C: do_one_cmd (ex_docmd.c:2640) ==3281==by 0x80A5255: do_cmdline (ex_docmd.c:1109) - This leak happens 2*n - 1 times n being the number of iteration of loop in leak.vim In this example: 2*5 - 1 - 9 blocks leaked Attached patch fixes it. Thanks, I'll include it. -- hundred-and-one symptoms of being an internet addict: 237. You tattoo your email address on your forehead. /// 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
Claimed memory leak in :match
A recent edit to a tip includes a claim that having :match in autocmd events leads to severe slow downs due to a memory leak. The tip has a variety of methods to highlight unwanted spaces, including the following extreme version which attempts to highlight dubious spaces as you type, but NOT highlight a trailing space at the end of a line as you are typing it: highlight ExtraWhitespace ctermbg=red guibg=red match ExtraWhitespace /\s\+$/ autocmd BufWinEnter * match ExtraWhitespace /\s\+$/ autocmd InsertEnter * match ExtraWhitespace /\s\+\%#\@!$/ autocmd InsertLeave * match ExtraWhitespace /\s\+$/ autocmd BufWinLeave * call clearmatches() The last line was just added with the claim that it is necessary to avoid severe slow downs. I probably won't have an opportunity to check this claim, and there is no indication of what version of Vim was used, but I thought I would mention this in case someone wants to investigate. The tip is: http://vim.wikia.com/wiki/Highlight_unwanted_spaces The difference showing the two recent edits is: http://vim.wikia.com/index.php?title=Highlight_unwanted_spacesdiff=27609oldid=27103 John -- 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: Claimed memory leak in :match
John Beckett wrote: A recent edit to a tip includes a claim that having :match in autocmd events leads to severe slow downs due to a memory leak. The tip has a variety of methods to highlight unwanted spaces, including the following extreme version which attempts to highlight dubious spaces as you type, but NOT highlight a trailing space at the end of a line as you are typing it: highlight ExtraWhitespace ctermbg=red guibg=red match ExtraWhitespace /\s\+$/ autocmd BufWinEnter * match ExtraWhitespace /\s\+$/ autocmd InsertEnter * match ExtraWhitespace /\s\+\%#\@!$/ autocmd InsertLeave * match ExtraWhitespace /\s\+$/ autocmd BufWinLeave * call clearmatches() The last line was just added with the claim that it is necessary to avoid severe slow downs. I probably won't have an opportunity to check this claim, and there is no indication of what version of Vim was used, but I thought I would mention this in case someone wants to investigate. The tip is: http://vim.wikia.com/wiki/Highlight_unwanted_spaces The difference showing the two recent edits is: http://vim.wikia.com/index.php?title=Highlight_unwanted_spacesdiff=27609oldid=27103 Well, the best way to find out if it's a leak or not is running Vim under valgrind. It will pinpoint the problem quickly. It's more likely that the look-behind part of the regexp (\@!) causes Vim to be very busy. -- hundred-and-one symptoms of being an internet addict: 179. You wonder why your household garbage can doesn't have an empty recycle bin button. /// 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
[patch] fixed memory leak in gVim (Motif GUI)
Hi I see the following memory leak in gVim-7.2.411 when built with the Motif GUI: ==15793== 6 bytes in 6 blocks are definitely lost in loss record 44 of 1,836 ==15793==at 0x4024F70: malloc (vg_replace_malloc.c:236) ==15793==by 0x43A4027: XtMalloc (in /usr/lib/libXt.so.6.0.0) ==15793==by 0x413C538: XmTextFieldGetString (in /usr/lib/libXm.so.2.0.1) ==15793==by 0x4138890: XmTextGetString (in /usr/lib/libXm.so.2.0.1) ==15793==by 0x81C73C9: gui_mch_dialog (gui_motif.c:2915) ==15793==by 0x80FDBF3: do_dialog (message.c:3318) ==15793==by 0x807D5F3: f_inputdialog (eval.c:12383) ==15793==by 0x80782A5: call_func (eval.c:8155) ==15793==by 0x8077DF7: get_func_tv (eval.c:7972) ==15793==by 0x80743CF: eval7 (eval.c:5019) ==15793==by 0x8073CE8: eval6 (eval.c:4686) ==15793==by 0x80738DE: eval5 (eval.c:4502) ==15793==by 0x8072E88: eval4 (eval.c:4197) ==15793==by 0x8072CF6: eval3 (eval.c:4109) ==15793==by 0x8072B98: eval2 (eval.c:4038) ==15793==by 0x80729E9: eval1 (eval.c:3963) ==15793==by 0x8072954: eval0 (eval.c:3920) ==15793==by 0x806F29B: ex_let (eval.c:1835) ==15793==by 0x80A22C8: do_one_cmd (ex_docmd.c:2629) ==15793==by 0x809FBA1: do_cmdline (ex_docmd.c:1098) ==15793==by 0x808BDF4: call_user_func (eval.c:21324) ==15793==by 0x80781A3: call_func (eval.c:8126) ==15793==by 0x8077DF7: get_func_tv (eval.c:7972) ==15793==by 0x8071B3E: ex_call (eval.c:3343) ==15793==by 0x80A22C8: do_one_cmd (ex_docmd.c:2629) ==15793==by 0x809FBA1: do_cmdline (ex_docmd.c:1098) ==15793==by 0x8123D4A: nv_colon (normal.c:5224) ==15793==by 0x811D5ED: normal_cmd (normal.c:1188) ==15793==by 0x80E16BA: main_loop (main.c:1211) ==15793==by 0x80E11B1: main (main.c:955) One block is leaked whenever you click on the icon Search Vim Help which is the icon most at the right in the icon toolbar. I clicked 6 times, and I observed 6 leaks for example. Caller of XmTextGetString(...) is meant to free the returned string by calling XtFree(...). See: http://linux.die.net/man/3/xmtextgetstring http://www.rahul.net/kenton/txa/mar96.html Attached patch fixes it. -- Dominique -- 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 To unsubscribe from this group, send email to vim_dev+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. diff -r 24100651daa9 src/gui_motif.c --- a/src/gui_motif.c Tue Mar 23 18:22:46 2010 +0100 +++ b/src/gui_motif.c Thu Mar 25 22:05:24 2010 +0100 @@ -2917,6 +2917,7 @@ *textfield = NUL; else vim_strncpy(textfield, p, IOSIZE - 1); + XtFree((char *)p); } suppress_dialog_mnemonics(dialogform);
Re: [patch] fixed memory leak when error E669 happens
Dominique Pelle wrote: Vim-7.2.315 is leaking memory whenever error E669 happens: ==4880== 18 bytes in 3 blocks are definitely lost in loss record 116 of 363 ==4880==at 0x4024F3C: malloc (vg_replace_malloc.c:195) ==4880==by 0x810E187: lalloc (misc2.c:866) ==4880==by 0x810E091: alloc (misc2.c:765) ==4880==by 0x810E5FA: vim_strnsave (misc2.c:1195) ==4880==by 0x819F4BC: syn_check_group (syntax.c:8621) ==4880==by 0x819BD0A: do_highlight (syntax.c:6751) ==4880==by 0x80A7BD0: ex_highlight (ex_docmd.c:6233) ==4880==by 0x80A2098: do_one_cmd (ex_docmd.c:2629) ==4880==by 0x809F971: do_cmdline (ex_docmd.c:1098) ==4880==by 0x80883B8: ex_execute (eval.c:19592) ==4880==by 0x80A2098: do_one_cmd (ex_docmd.c:2629) ==4880==by 0x809F971: do_cmdline (ex_docmd.c:1098) ==4880==by 0x8123C34: nv_colon (normal.c:5224) ==4880==by 0x811D631: normal_cmd (normal.c:1188) ==4880==by 0x80E12BD: main_loop (main.c:1204) ==4880==by 0x80E0DB4: main (main.c:948) Leak happens when trying to add a highlight group with non-printable characters. Following command for example will cause a leak: :exe hi \c-v\c-a term=bold Attached patch fixes it. Thanks! -- The technology involved in making anything invisible is so infinitely complex that nine hundred and ninety-nine billion, nine hundred and ninety-nine million, nine hundred and ninety-nine thousand, nine hundred and ninety-nine times out of a trillion it is much simpler and more effective just to take the thing away and do without it. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy /// 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. For more information, visit http://www.vim.org/maillist.php
Re: [patch] fixed memory leak in hlsearch
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
-~--~~~~--~~--~--~---
Re: [patch] fixed memory leak in hlsearch
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. -- wie...@porcupine.org
/// 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.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: [patch] fixed memory leak in hlsearch
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.
Thanks!
--
ARTHUR: Old woman!
DENNIS: Man!
ARTHUR: Man. I'm sorry. Old man, What knight live in that castle over there?
DENNIS: I'm thirty-seven.
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// 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.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[patch] fixed memory leak in :set term=builtin_dumb
I notice a memory leak in Vim-7.2.233 (and older) whenever I do:
:set term=builtin_dumb
If you execute above command n times, it will leak n blocks of memory.
Memory is allocated here:
==13315== 10 bytes in 2 blocks are definitely lost in loss record 127 of 162
==13315==at 0x402603E: malloc (vg_replace_malloc.c:207)
==13315==by 0x812F556: lalloc (misc2.c:866)
==13315==by 0x812F461: alloc (misc2.c:765)
==13315==by 0x812F96A: vim_strsave (misc2.c:1177)
==13315==by 0x815A459: set_string_option_direct (option.c:5353)
==13315==by 0x81CA9B1: set_color_count (term.c:1565)
==13315==by 0x81CAD91: set_termname (term.c:1740)
==13315==by 0x815A843: did_set_string_option (option.c:5497)
==13315==by 0x81593CE: do_set (option.c:4678)
==13315==by 0x80CED24: ex_set (ex_docmd.c:10983)
==13315==by 0x80C1F94: do_one_cmd (ex_docmd.c:2627)
==13315==by 0x80BF7CB: do_cmdline (ex_docmd.c:1096)
==13315==by 0x81457EA: nv_colon (normal.c:5224)
==13315==by 0x813F03E: normal_cmd (normal.c:1188)
==13315==by 0x8101DB5: main_loop (main.c:1186)
==13315==by 0x8101902: main (main.c:942)
option.c:
5353 s = vim_strsave(val);
5354 if (s != NULL)
5355 {
5356 varp = (char_u **)get_varp_scope((options[idx]),
5357 both ? OPT_LOCAL : opt_flags);
5358 if ((opt_flags OPT_FREE) (options[idx].flags P_ALLOCED))
5359 free_string_option(*varp);
5360 *varp = s;
Chasing with gdb, I found that the leak happens shortly later
in term.c in ttest():
2882 /* if 'Sb' and 'AB' are not defined, reset Co */
2883 if (*T_CSB == NUL *T_CAB == NUL)
2884 T_CCO = empty_option; LEAK!
Line 2884 replaces T_CCO, which had been previously dynamically
allocated in option.c:5353, by empty_option. T_CCO should be freed
before being replaced (I assume T_CCO is always dynamically allocated
if it was not empty_option).
Attached patch fixes it.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: term.c
===
RCS file: /cvsroot/vim/vim7/src/term.c,v
retrieving revision 1.39
diff -c -r1.39 term.c
*** term.c 16 Jun 2009 12:31:33 - 1.39
--- term.c 14 Jul 2009 19:34:00 -
***
*** 2880,2887
}
/* if 'Sb' and 'AB' are not defined, reset Co */
! if (*T_CSB == NUL *T_CAB == NUL)
T_CCO = empty_option;
/* Set 'weirdinvert' according to value of 't_xs' */
p_wiv = (*T_XS != NUL);
--- 2880,2890
}
/* if 'Sb' and 'AB' are not defined, reset Co */
! if (*T_CSB == NUL *T_CAB == NUL T_CCO != empty_option)
! {
! vim_free(T_CCO);
T_CCO = empty_option;
+ }
/* Set 'weirdinvert' according to value of 't_xs' */
p_wiv = (*T_XS != NUL);
Re: [patch] fixed memory leak in :set term=builtin_dumb
Dominique Pelle wrote:
I notice a memory leak in Vim-7.2.233 (and older) whenever I do:
:set term=builtin_dumb
If you execute above command n times, it will leak n blocks of memory.
Memory is allocated here:
==13315== 10 bytes in 2 blocks are definitely lost in loss record 127 of 162
==13315==at 0x402603E: malloc (vg_replace_malloc.c:207)
==13315==by 0x812F556: lalloc (misc2.c:866)
==13315==by 0x812F461: alloc (misc2.c:765)
==13315==by 0x812F96A: vim_strsave (misc2.c:1177)
==13315==by 0x815A459: set_string_option_direct (option.c:5353)
==13315==by 0x81CA9B1: set_color_count (term.c:1565)
==13315==by 0x81CAD91: set_termname (term.c:1740)
==13315==by 0x815A843: did_set_string_option (option.c:5497)
==13315==by 0x81593CE: do_set (option.c:4678)
==13315==by 0x80CED24: ex_set (ex_docmd.c:10983)
==13315==by 0x80C1F94: do_one_cmd (ex_docmd.c:2627)
==13315==by 0x80BF7CB: do_cmdline (ex_docmd.c:1096)
==13315==by 0x81457EA: nv_colon (normal.c:5224)
==13315==by 0x813F03E: normal_cmd (normal.c:1188)
==13315==by 0x8101DB5: main_loop (main.c:1186)
==13315==by 0x8101902: main (main.c:942)
option.c:
5353 s = vim_strsave(val);
5354 if (s != NULL)
5355 {
5356 varp = (char_u **)get_varp_scope((options[idx]),
5357 both ? OPT_LOCAL :
opt_flags);
5358 if ((opt_flags OPT_FREE) (options[idx].flags P_ALLOCED))
5359 free_string_option(*varp);
5360 *varp = s;
Chasing with gdb, I found that the leak happens shortly later
in term.c in ttest():
2882 /* if 'Sb' and 'AB' are not defined, reset Co */
2883 if (*T_CSB == NUL *T_CAB == NUL)
2884 T_CCO = empty_option; LEAK!
Line 2884 replaces T_CCO, which had been previously dynamically
allocated in option.c:5353, by empty_option. T_CCO should be freed
before being replaced (I assume T_CCO is always dynamically allocated
if it was not empty_option).
Attached patch fixes it.
Thanks!
--
From know your smileys:
:-)-O Smiling doctor with stethoscope
/// 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.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[patch] fixed memory leak in Ex command :fu[nction] /{pattern}
Hi
Valgrind memory checker detects the following memory leak in Vim-7.2.148:
==26113== 36 bytes in 1 blocks are definitely lost in loss record 23 of 41
==26113==at 0x402603E: malloc (vg_replace_malloc.c:207)
==26113==by 0x8113A62: lalloc (misc2.c:866)
==26113==by 0x8158375: vim_regcomp (regexp.c:1021)
==26113==by 0x808CE03: ex_function (eval.c:19765)
==26113==by 0x80A6807: do_one_cmd (ex_docmd.c:2622)
==26113==by 0x80A4087: do_cmdline (ex_docmd.c:1096)
==26113==by 0x8129E72: nv_colon (normal.c:5218)
==26113==by 0x81234D6: normal_cmd (normal.c:1189)
==26113==by 0x80E6655: main_loop (main.c:1180)
==26113==by 0x80E61A2: main (main.c:939)
Leak happens whenever typing Ex command :fu[nction] /{pattern}
which lists function names matching {pattern}.
For example, this will cause a memory leak:
$ vim -u NONE
:function! Foo
:endfunction
:function /F
Attached patch fixes it.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.280
diff -c -r1.280 eval.c
*** eval.c 4 Feb 2009 15:27:06 - 1.280
--- eval.c 18 Apr 2009 07:30:06 -
***
*** 19780,19785
--- 19780,19786
list_func_head(fp, FALSE);
}
}
+ vim_free(regmatch.regprog);
}
}
if (*p == '/')
Re: [patch] fixed memory leak in Ex command :fu[nction] /{pattern}
Dominique Pelle wrote:
Valgrind memory checker detects the following memory leak in Vim-7.2.148:
==26113== 36 bytes in 1 blocks are definitely lost in loss record 23 of 41
==26113==at 0x402603E: malloc (vg_replace_malloc.c:207)
==26113==by 0x8113A62: lalloc (misc2.c:866)
==26113==by 0x8158375: vim_regcomp (regexp.c:1021)
==26113==by 0x808CE03: ex_function (eval.c:19765)
==26113==by 0x80A6807: do_one_cmd (ex_docmd.c:2622)
==26113==by 0x80A4087: do_cmdline (ex_docmd.c:1096)
==26113==by 0x8129E72: nv_colon (normal.c:5218)
==26113==by 0x81234D6: normal_cmd (normal.c:1189)
==26113==by 0x80E6655: main_loop (main.c:1180)
==26113==by 0x80E61A2: main (main.c:939)
Leak happens whenever typing Ex command :fu[nction] /{pattern}
which lists function names matching {pattern}.
For example, this will cause a memory leak:
$ vim -u NONE
:function! Foo
:endfunction
:function /F
Attached patch fixes it.
Thanks again.
--
[clop clop]
MORTICIAN: Who's that then?
CUSTOMER: I don't know.
MORTICIAN: Must be a king.
CUSTOMER: Why?
MORTICIAN: He hasn't got shit all over him.
The Quest for the Holy Grail (Monty Python)
/// 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.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: [patch] fixed memory leak in :recover command
Dominique Pelle wrote:
Valgrind memory checker detects the following memory leak in Vim-7.2.148:
==12545== 264 bytes in 4 blocks are definitely lost in loss record 20 of 41
==12545==at 0x402603E: malloc (vg_replace_malloc.c:207)
==12545==by 0x811440D: lalloc (misc2.c:866)
==12545==by 0x8114318: alloc (misc2.c:765)
==12545==by 0x80F68EF: recover_names (memline.c:1536)
==12545==by 0x80F553E: ml_recover (memline.c:891)
==12545==by 0x80AD962: ex_recover (ex_docmd.c:7074)
==12545==by 0x80A6D4B: do_one_cmd (ex_docmd.c:2622)
==12545==by 0x80A45CB: do_cmdline (ex_docmd.c:1096)
==12545==by 0x812A88A: nv_colon (normal.c:5218)
==12545==by 0x8123EEE: normal_cmd (normal.c:1189)
==12545==by 0x80E6C89: main_loop (main.c:1180)
==12545==by 0x80E67D6: main (main.c:939)
Bug can easily be reproduced as follows:
1/ Create an empty directory
$ mkdir /tmp/empty_dir
2/ Then whenever the following Ex command is entered in Vim,
a memory leak happens:
:recover /tmp/empty_dir/
Memory is allocated in memline.c:1536
1532if (swapname != NULL)
1533{
1534if (mch_stat((char *)swapname, st) != -1) /* It exists! */
1535{
1536files = (char_u **)alloc((unsigned)sizeof(char_u *));
1537if (files != NULL)
1538{
1539files[0] = swapname;
1540swapname = NULL;
1541num_files = 1;
1542}
num_files is set to 1 at line 1541. Then files[0] is freed at
line 1557 (but files is not freed) and num_files is decremented
from 1 to 0:
1554 for (i = 0; i num_files; ++i)
1555 if (fullpathcmp(p, files[i], TRUE) FPC_SAME)
1556 {
1557 vim_free(files[i]);
1558 --num_files;
files is then no longer freed (leak) since lines that would free it
is is inside 'if (num_files 0)':
1609 if (num_files 0)
1610 FreeWild(num_files, files);
Attached patch fixes it.
Thanks!
--
CUSTOMER: You're not fooling anyone y'know. Look, isn't there something
you can do?
DEAD PERSON: I feel happy... I feel happy.
[whop]
CUSTOMER: Ah, thanks very much.
MORTICIAN:Not at all. See you on Thursday.
CUSTOMER: Right.
The Quest for the Holy Grail (Monty Python)
/// 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.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: [patch] fixed memory leak in command custom completion
Dominique Pelle wrote: Command custom completion (:help :command-completion-customlist) is leaking memory when redefining completion for a command multiple times. I see this bug in latest Vim-7.2.132. The following script illustrates the problem: memory usage keeps growing at each iteration when redefining a command completion: :function! s:Foo() :endfunction :function! s:CompleteFoo(a, l, p) :endfunction :while 1 : Leak at each iteration : command! -complete=customlist,s:CompleteFoo -nargs=1 Foo :call s:Foo() :endwhile Attached patch fixes the memory leak. Thanks! I'll move the vim_free() call to where uc_rep is freed, they belong together. -- What is the difference between a professional and an amateur? The ark was built by an amateur; professionals gave us the Titanic. /// 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. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] fixed memory leak in command custom completion
Hi
Command custom completion (:help :command-completion-customlist)
is leaking memory when redefining completion for a command
multiple times. I see this bug in latest Vim-7.2.132.
The following script illustrates the problem: memory usage keeps
growing at each iteration when redefining a command completion:
:function! s:Foo()
:endfunction
:function! s:CompleteFoo(a, l, p)
:endfunction
:while 1
: Leak at each iteration
: command! -complete=customlist,s:CompleteFoo -nargs=1 Foo :call s:Foo()
:endwhile
Attached patch fixes the memory leak.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: ex_docmd.c
===
RCS file: /cvsroot/vim/vim7/src/ex_docmd.c,v
retrieving revision 1.166
diff -c -r1.166 ex_docmd.c
*** ex_docmd.c 1 Mar 2009 01:45:15 - 1.166
--- ex_docmd.c 10 Mar 2009 19:24:08 -
***
*** 5148,5153
--- 5148,5157
cmd-uc_name = p;
}
+ #if defined(FEAT_EVAL) defined(FEAT_CMDL_COMPL)
+ else
+ vim_free(cmd-uc_compl_arg); /* free previous compl. arg if any */
+ #endif
cmd-uc_rep = rep_buf;
cmd-uc_argt = argt;
***
*** 5941,5947
for (;;)
{
p = cmd-uc_rep;/* source */
! q = buf; /* destinateion */
totlen = 0;
for (;;)
--- 5945,5951
for (;;)
{
p = cmd-uc_rep;/* source */
! q = buf; /* destination */
totlen = 0;
for (;;)
[patch] fixed memory leak when deleting buffer with spell checking
Hi
The following vim script leaks memory at each iteration, using
latest Vim-7.2.25:
:set spell
:while 1
:copen
:bd
:endwhile
Run this script with 'vim -u NONE -S leak.vim' and watch memory
increasing steadily. Valgrind reports this leak:
$ valgrind --leak-check=yes --num-callers=20 vim -u NONE -S leak.vim
...
==14170== 124,288 bytes in 3,884 blocks are definitely lost in loss
record 65 of 65
==14170==at 0x4022AE8: malloc (vg_replace_malloc.c:207)
==14170==by 0x81127C4: lalloc (misc2.c:859)
==14170==by 0x81126FB: alloc_clear (misc2.c:770)
==14170==by 0x811370D: ga_grow (misc2.c:1981)
==14170==by 0x817E875: did_set_spelllang (spell.c:4261)
==14170==by 0x8097922: do_ecmd (ex_cmds.c:3704)
==14170==by 0x8152AC1: ex_copen (quickfix.c:2336)
==14170==by 0x80A61E1: do_one_cmd (ex_docmd.c:2621)
==14170==by 0x80A3A84: do_cmdline (ex_docmd.c:1095)
==14170==by 0x80A1D20: do_source (ex_cmds2.c:3114)
==14170==by 0x80A163B: cmd_source (ex_cmds2.c:2741)
==14170==by 0x80A158F: ex_source (ex_cmds2.c:2714)
==14170==by 0x80A61E1: do_one_cmd (ex_docmd.c:2621)
==14170==by 0x80A3A84: do_cmdline (ex_docmd.c:1095)
==14170==by 0x80A3124: do_cmdline_cmd (ex_docmd.c:701)
==14170==by 0x80E7600: exe_commands (main.c:2683)
==14170==by 0x80E500F: main (main.c:873)
The number of blocks leaked (3,884 here) is the number of
iterations in the loop before I hit Ctrl-C.
I'm using Vim-7.2.25, built with -O0 on Linux x86.
Attached patch fixes it (+ typos in comments).
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: buffer.c
===
RCS file: /cvsroot/vim/vim7/src/buffer.c,v
retrieving revision 1.83
diff -c -r1.83 buffer.c
*** buffer.c 1 Sep 2008 15:32:55 - 1.83
--- buffer.c 22 Oct 2008 01:55:20 -
***
*** 647,652
--- 647,655
vim_free(buf-b_start_fenc);
buf-b_start_fenc = NULL;
#endif
+ #ifdef FEAT_SPELL
+ ga_clear(buf-b_langp);
+ #endif
}
/*
***
*** 1880,1886
* buf if one exists */
if (swb_flags SWB_USEOPEN)
wp = buf_jump_open_win(buf);
! /* If 'switchbuf' contians usetab: jump to first window in any tab
* page containing buf if one exists */
if (wp == NULL (swb_flags SWB_USETAB))
wp = buf_jump_open_tab(buf);
--- 1883,1889
* buf if one exists */
if (swb_flags SWB_USEOPEN)
wp = buf_jump_open_win(buf);
! /* If 'switchbuf' contains usetab: jump to first window in any tab
* page containing buf if one exists */
if (wp == NULL (swb_flags SWB_USETAB))
wp = buf_jump_open_tab(buf);
***
*** 3964,3970
width = vim_strsize(out);
if (maxwidth 0 width maxwidth)
{
! /* Result is too long, must trunctate somewhere. */
l = 0;
if (itemcnt == 0)
s = out;
--- 3967,3973
width = vim_strsize(out);
if (maxwidth 0 width maxwidth)
{
! /* Result is too long, must truncate somewhere. */
l = 0;
if (itemcnt == 0)
s = out;
Re: [patch] fixed memory leak in do_sub() ex_cmds.c
Dominique Pelle wrote:
Valgrind memory checker finds a memory leak in Vim-7.2.15.
The steps to reproduce are a bit too messy to describe here
and I have not been able to find a simple way to reproduce it.
However I can reproduce it 100% of the time:
Perhaps this happens when undo is disabled?
==1182== 150 bytes in 2 blocks are definitely lost in loss record 24 of 34
==1182==at 0x4C21FEB: malloc (vg_replace_malloc.c:207)
==1182==by 0x4D6927: lalloc (misc2.c:859)
==1182==by 0x4D689A: alloc_check (misc2.c:792)
==1182==by 0x457EC4: do_sub (ex_cmds.c:4822)
==1182==by 0x465561: do_one_cmd (ex_docmd.c:2621)
==1182==by 0x462D41: do_cmdline (ex_docmd.c:1095)
==1182==by 0x45FE46: ex_listdo (ex_cmds2.c:2374)
==1182==by 0x465561: do_one_cmd (ex_docmd.c:2621)
==1182==by 0x462D41: do_cmdline (ex_docmd.c:1095)
==1182==by 0x4EE779: nv_colon (normal.c:5214)
==1182==by 0x4E775D: normal_cmd (normal.c:1181)
==1182==by 0x4A79EF: main_loop (main.c:1179)
==1182==by 0x4A7535: main (main.c:938)
I see at least 2 'break' statements that would cause such
a leak at lines 4994 and line 5007 in ex_cmds.c:
4979 if (new_start != NULL)
4980 {
4981 /*
4982 * Copy the rest of the line, that didn't match.
4983 * matchcol has to be adjusted, we use
the end of
4984 * the line as reference, because the
substitute m
4985 * have changed the number of
characters. Same for
4986 * prev_matchcol.
4987 */
4988 STRCAT(new_start, sub_firstline + copycol);
4989 matchcol =
(colnr_T)STRLEN(sub_firstline) - matchc
4990 prev_matchcol = (colnr_T)STRLEN(sub_firstline)
4991 -
prev_match
4992
4993 if (u_savesub(lnum) != OK)
!4994 break;
4995 ml_replace(lnum, new_start, TRUE);
4996
4997 if (nmatch_tl 0)
4998 {
4999 /*
5000 * Matched lines have now been
substituted and
5001 * useless, delete them. The part
after the m
5002 * has been appended to new_start,
we don't ne
5003 * it in the buffer.
5004 */
5005 ++lnum;
5006 if (u_savedel(lnum, nmatch_tl) != OK)
!5007 break;
Attached patch fixes it.
Thanks. I'll include it.
--
The real
trick is
this: to
keep the
lines as
short as
possible
and keep
the size
the same
yet free
from the
need for
hyphena-
Dammit!! (Matthew Winn)
/// 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: [patch] fixed memory leak in do_sub() ex_cmds.c
On Sat, Sep 13, 2008 at 4:09 PM, Bram Moolenaar wrote: Dominique Pelle wrote: Valgrind memory checker finds a memory leak in Vim-7.2.15. The steps to reproduce are a bit too messy to describe here and I have not been able to find a simple way to reproduce it. However I can reproduce it 100% of the time: Perhaps this happens when undo is disabled? It happened when I did: :argdo %s/foo/bar/g The substitute command tried to modify a readonly file which triggered perforce plugin to ask to checkout the file, I pressed ctrl-c to interrupt. Then when exiting I found the leak. I could reproduce it all the time. Perhaps the argdo is not necessary, I won't have access to my development machine for a few weeks to try anything. But the bug is pretty clear from looking at the code anyway I think. A printf confirmed that leak happened when u_savesub(lnum) at line 4993 returned != OK and break statement at line 4994 caused the leak: 4993 if (u_savesub(lnum) != OK) !4994 break; -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] fixed memory leak in do_sub() ex_cmds.c
Hi
Valgrind memory checker finds a memory leak in Vim-7.2.15.
The steps to reproduce are a bit too messy to describe here
and I have not been able to find a simple way to reproduce it.
However I can reproduce it 100% of the time:
==1182== 150 bytes in 2 blocks are definitely lost in loss record 24 of 34
==1182==at 0x4C21FEB: malloc (vg_replace_malloc.c:207)
==1182==by 0x4D6927: lalloc (misc2.c:859)
==1182==by 0x4D689A: alloc_check (misc2.c:792)
==1182==by 0x457EC4: do_sub (ex_cmds.c:4822)
==1182==by 0x465561: do_one_cmd (ex_docmd.c:2621)
==1182==by 0x462D41: do_cmdline (ex_docmd.c:1095)
==1182==by 0x45FE46: ex_listdo (ex_cmds2.c:2374)
==1182==by 0x465561: do_one_cmd (ex_docmd.c:2621)
==1182==by 0x462D41: do_cmdline (ex_docmd.c:1095)
==1182==by 0x4EE779: nv_colon (normal.c:5214)
==1182==by 0x4E775D: normal_cmd (normal.c:1181)
==1182==by 0x4A79EF: main_loop (main.c:1179)
==1182==by 0x4A7535: main (main.c:938)
I see at least 2 'break' statements that would cause such
a leak at lines 4994 and line 5007 in ex_cmds.c:
4979 if (new_start != NULL)
4980 {
4981 /*
4982 * Copy the rest of the line, that didn't match.
4983 * matchcol has to be adjusted, we use
the end of
4984 * the line as reference, because the
substitute m
4985 * have changed the number of
characters. Same for
4986 * prev_matchcol.
4987 */
4988 STRCAT(new_start, sub_firstline + copycol);
4989 matchcol =
(colnr_T)STRLEN(sub_firstline) - matchc
4990 prev_matchcol = (colnr_T)STRLEN(sub_firstline)
4991 -
prev_match
4992
4993 if (u_savesub(lnum) != OK)
!4994 break;
4995 ml_replace(lnum, new_start, TRUE);
4996
4997 if (nmatch_tl 0)
4998 {
4999 /*
5000 * Matched lines have now been
substituted and
5001 * useless, delete them. The part
after the m
5002 * has been appended to new_start,
we don't ne
5003 * it in the buffer.
5004 */
5005 ++lnum;
5006 if (u_savedel(lnum, nmatch_tl) != OK)
!5007 break;
Attached patch fixes it.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: ex_cmds.c
===
RCS file: /cvsroot/vim/vim7/src/ex_cmds.c,v
retrieving revision 1.113
diff -c -r1.113 ex_cmds.c
*** ex_cmds.c 6 Aug 2008 13:03:07 - 1.113
--- ex_cmds.c 11 Sep 2008 18:22:00 -
***
*** 5059,5064
--- 5059,5065
if (did_sub)
++sub_nlines;
+ vim_free(new_start);
vim_free(sub_firstline); /* free the copy of the original line */
sub_firstline = NULL;
}
[patch] fixed memory leak in fileio.c (with HAVE_ACL)
Hi
Valgrind memory checker detects the following memory leak:
==2410== 272 (56 direct, 216 indirect) bytes in 1 blocks are
definitely lost in loss record 2
==2410==at 0x4C21FEB: malloc (vg_replace_malloc.c:207)
==2410==by 0x6F7548A: (within /lib64/libacl.so.1.1.0)
==2410==by 0x6F73EE6: (within /lib64/libacl.so.1.1.0)
==2410==by 0x6F746F1: acl_from_mode (in /lib64/libacl.so.1.1.0)
==2410==by 0x6F73D2F: acl_get_file (in /lib64/libacl.so.1.1.0)
==2410==by 0x50FFDC: mch_get_acl (os_unix.c:2658)
==2410==by 0x4895C5: vim_rename (fileio.c:6163)
==2410==by 0x4B58A2: ml_setname (memline.c:467)
==2410==by 0x4123CE: buf_name_changed (buffer.c:2698)
==2410==by 0x4122FE: setfname (buffer.c:2657)
==2410==by 0x453DE7: ex_file (ex_cmds.c:2464)
==2410==by 0x465179: do_one_cmd (ex_docmd.c:2621)
==2410==by 0x462959: do_cmdline (ex_docmd.c:1095)
==2410==by 0x4EDE83: nv_colon (normal.c:5181)
==2410==by 0x4E6E73: normal_cmd (normal.c:1152)
==2410==by 0x4A73A1: main_loop (main.c:1177)
==2410==by 0x4A6EED: main (main.c:936)
I can reproduce it with Vim-7.2a BETA (huge) built with libacl and using
a file system mounted with acl option on Linux x86_64.
Here is how I can reproduce it 100% of the time (there might be other ways):
1/ Start Vim with Valgrind:
$ valgrind --leak-check=yes vim -u NONE /tmp/foo 2 vg.log
2/ Change the file name to a location on a filesystem mounted with acl and where
you don't have write permission (/ for example for me):
:file /foo
For me, / is the following filesystem (note the acl mount option)
/dev/sda2 on / type reiserfs (rw,acl,user_xattr)
3/ Quit Vim :q and observe in vg.log that Valgrind detected a leak (as
many leaks as :file /foo command was entered)
I attach a patch which fixes it.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: fileio.c
===
RCS file: /cvsroot/vim/vim7/src/fileio.c,v
retrieving revision 1.117
diff -c -r1.117 fileio.c
*** fileio.c 24 Jun 2008 21:02:45 - 1.117
--- fileio.c 26 Jun 2008 08:27:57 -
***
*** 2456,2462
/*
* Work around a weird problem: When a file has two links (only
* possible on NTFS) and we write through one link, then stat() it
! * throught the other link, the timestamp information may be wrong.
* It's correct again after reading the file, thus reset the timestamp
* here.
*/
--- 2456,2462
/*
* Work around a weird problem: When a file has two links (only
* possible on NTFS) and we write through one link, then stat() it
! * through the other link, the timestamp information may be wrong.
* It's correct again after reading the file, thus reset the timestamp
* here.
*/
***
*** 3906,3912
#ifdef VMS
vms_remove_version(fname); /* remove version */
#endif
! /* Default: write the the file directly. May write to a temp file for
* multi-byte conversion. */
wfname = fname;
--- 3906,3912
#ifdef VMS
vms_remove_version(fname); /* remove version */
#endif
! /* Default: write the file directly. May write to a temp file for
* multi-byte conversion. */
wfname = fname;
***
*** 5770,5776
#endif
/*
! * add extention to file name - change path/fo.o.h to path/fo.o.h.ext or
* fo_o_h.ext for MSDOS or when shortname option set.
*
* Assumed that fname is a valid name found in the filesystem we assure that
--- 5770,5776
#endif
/*
! * add extension to file name - change path/fo.o.h to path/fo.o.h.ext or
* fo_o_h.ext for MSDOS or when shortname option set.
*
* Assumed that fname is a valid name found in the filesystem we assure that
***
*** 5952,5958
#endif
/*
! * Append the extention.
* ext can start with '.' and cannot exceed 3 more characters.
*/
STRCPY(s, ext);
--- 5952,5958
#endif
/*
! * Append the extension.
* ext can start with '.' and cannot exceed 3 more characters.
*/
STRCPY(s, ext);
***
*** 6164,6176
--- 6164,6184
#endif
fd_in = mch_open((char *)from, O_RDONLY|O_EXTRA, 0);
if (fd_in == -1)
+ {
+ #ifdef HAVE_ACL
+ mch_free_acl(acl);
+ #endif
return -1;
+ }
/* Create the new file with same permissions as the original. */
fd_out = mch_open((char *)to,
O_CREAT|O_EXCL|O_WRONLY|O_EXTRA|O_NOFOLLOW, (int)perm);
if (fd_out == -1)
{
+ #ifdef HAVE_ACL
+ mch_free_acl(acl);
+ #endif
close(fd_in);
return -1;
}
***
*** 6178,6183
--- 6186,6194
buffer = (char *)alloc(BUFSIZE);
if (buffer == NULL
Re: [patch] fixed memory leak in digraph.c
Dominique Pelle wrote: Vim is leaking memory when doing 'set keymap=' You can reproduce the memory leak by running the following script and observe memory usage (with 'top') which keeps increasing continuously: :while 1 : set keymap=esperanto : set keymap= :endwhile The leak happens regardless of the keymap, I only chose 'esperanto' as an example. The same leak also happens when doing 'set arabic' 'set noarabic' since it implies a 'set keymap=arabic'. Valgrind memory checker points to following location for the leak: ==7572== 4,856,970 bytes in 571,416 blocks are definitely lost in loss record 42 of 42 ==7572==at 0x4022AB8: malloc (vg_replace_malloc.c:207) ==7572==by 0x810FA74: lalloc (misc2.c:862) ==7572==by 0x810F990: alloc (misc2.c:761) ==7572==by 0x810FE2B: vim_strnsave (misc2.c:1179) ==7572==by 0x8062AA5: ex_loadkeymap (digraph.c:2493) ==7572==by 0x80A42F1: do_one_cmd (ex_docmd.c:2625) ==7572==by 0x80A1B98: do_cmdline (ex_docmd.c:1099) ==7572==by 0x809FE48: do_source (ex_cmds2.c:3119) ==7572==by 0x809F35F: source_callback (ex_cmds2.c:2563) ==7572==by 0x809F53C: do_in_runtimepath (ex_cmds2.c:2657) ==7572==by 0x809F389: source_runtime (ex_cmds2.c:2577) ==7572==by 0x806289F: keymap_init (digraph.c:2429) ==7572==by 0x813B623: did_set_string_option (option.c:5782) ==7572==by 0x81397C0: do_set (option.c:4659) ==7572==by 0x80B0F19: ex_set (ex_docmd.c:10862) ==7572==by 0x80A42F1: do_one_cmd (ex_docmd.c:2625) ==7572==by 0x80A1B98: do_cmdline (ex_docmd.c:1099) ==7572==by 0x809FE48: do_source (ex_cmds2.c:3119) ==7572==by 0x809F763: cmd_source (ex_cmds2.c:2746) ==7572==by 0x809F6B7: ex_source (ex_cmds2.c:2719) ==7572==by 0x80A42F1: do_one_cmd (ex_docmd.c:2625) ==7572==by 0x80A1B98: do_cmdline (ex_docmd.c:1099) ==7572==by 0x80A1238: do_cmdline_cmd (ex_docmd.c:705) ==7572==by 0x80E5357: exe_commands (main.c:2665) ==7572==by 0x80E2D87: main (main.c:875) Attached patch fixes it. I'm using Vim 7.1.330 (huge) on Linux x86. Good catch! -- hundred-and-one symptoms of being an internet addict: 88. Every single time you press the 'Get mail' button...it does get new mail. /// 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: [patch] fixed compilation warnings + memory leak + crash (lesstif)
On Sun, Jun 8, 2008 at 2:25 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: Dominique Pelle wrote: On Sat, Jun 7, 2008 at 8:44 AM, Dominique Pelle wrote: Attached: - crash-os_unix.c.patch - leak-os_unix.c.patch I built the gui-motif, gui-athena and gui-gtk2 on Linux x86 and the crash in os_unix.c only happens with gui-motif (I'm using LessTif). So instead of doing #if 0 as in my previous patch, it should be better to do #ifndef FEAT_GUI_MOTIF. gui-athena shows errors with -DEXITFREE just a few lines below though: ==15738== Invalid read of size 4 ==15738==at 0x42CDEE7: XCloseDisplay (in /usr/lib/libX11.so.6.2.0) ==15738==by 0x8140419: mch_free_mem (os_unix.c:2900) ==15738==by 0x810A969: free_all_mem (misc2.c:1125) ==15738==by 0x8140573: mch_exit (os_unix.c:3012) ==15738==by 0x80DE4C8: getout (main.c:1342) ==15738==by 0x80A56C3: ex_quit_all (ex_docmd.c:6281) ==15738==by 0x809F8CB: do_one_cmd (ex_docmd.c:2623) ==15738==by 0x809D18C: do_cmdline (ex_docmd.c:1099) ==15738==by 0x812030E: nv_colon (normal.c:5179) ==15738==by 0x8119B88: normal_cmd (normal.c:1152) ==15738==by 0x80DE20A: main_loop (main.c:1181) ==15738==by 0x80DDD5A: main (main.c:940) ==15738== Address 0x44020cc is 148 bytes inside a block of size 1,340 free'd ==15738==at 0x402265C: free (vg_replace_malloc.c:323) ==15738==by 0x42E0F3E: _XFreeDisplayStructure (in /usr/lib/libX11.so.6.2.0) ==15738==by 0x42CDFC5: XCloseDisplay (in /usr/lib/libX11.so.6.2.0) ==15738==by 0x424EC49: (within /usr/lib/libXt.so.6.0.0) ==15738==by 0x424EE36: XtCloseDisplay (in /usr/lib/libXt.so.6.0.0) ==15738==by 0x424EE70: (within /usr/lib/libXt.so.6.0.0) ==15738==by 0x424F164: XtDestroyApplicationContext (in /usr/lib/libXt.so.6.0.0) ==15738==by 0x81403F4: mch_free_mem (os_unix.c:2896) ==15738==by 0x810A969: free_all_mem (misc2.c:1125) ==15738==by 0x8140573: mch_exit (os_unix.c:3012) ==15738==by 0x80DE4C8: getout (main.c:1342) ==15738==by 0x80A56C3: ex_quit_all (ex_docmd.c:6281) ==15738==by 0x809F8CB: do_one_cmd (ex_docmd.c:2623) ==15738==by 0x809D18C: do_cmdline (ex_docmd.c:1099) ==15738==by 0x812030E: nv_colon (normal.c:5179) ==15738==by 0x8119B88: normal_cmd (normal.c:1152) ==15738==by 0x80DE20A: main_loop (main.c:1181) ==15738==by 0x80DDD5A: main (main.c:940) os_unix.c: 2890 # if (defined(FEAT_X11) defined(FEAT_XCLIPBOARD)) || defined(PROTO) 2891 if (xterm_Shell != (Widget)0) 2892 XtDestroyWidget(xterm_Shell); 2893 if (xterm_dpy != NULL) 2894 XtCloseDisplay(xterm_dpy); 2895 if (app_context != (XtAppContext)NULL) !! 2896 XtDestroyApplicationContext(app_context); 2897 # endif 2898 # ifdef FEAT_X11 2899 if (x11_display != NULL x11_display != xterm_dpy) !! 2900 XCloseDisplay(x11_display); 2901 # endif Line 2900 is using memory which was freed at line 2896 according to valgrind. So it seems that XtDestroyApplicationContext(app_context) is also destroying x11_display. Attached patch fixes the error. Thanks. I wonder if we can use #ifndef LESSTIF_VERSION instead of FEAT_GUI_MOTIF. The other #if 0 suggests that Solaris also has this problem. But I'm not sure about this specific code, since it was added much later. Yes, #ifndef LESSTIF_VERSION is better than #ifndef FEAT_GUI_MOTIF. I tested it with both lesstif and Open Motif, it's fine. After the attached patch, neither lesstif, nor Open Motif access freed memory. Open Motif needs the same fix as for athena gui i.e. set x11_display to NULL after 'XtDestroyApplicationContext(app_context);' since it seems to take care of already calling 'XCloseDisplay(x11_display)'. Lesstif and Open Motif also use uninitialized memory but I assume that's a problem in those libs and not with Vim. There are several things not freed with all GUIs (athena, open motif lesstif, gtk2, gnome2) when exiting even with -DEXITFREE but that's not a major problem I think. I fixed at least the following leak which happens at least for Motif and athena gui (patch: leak-gui_x11.c). ==23613== 32 bytes in 1 blocks are definitely lost in loss record 34 of 126 ==23613==at 0x4022AB8: malloc (vg_replace_malloc.c:207) ==23613==by 0x40A8C08: xpmParseDataAndCreate (in /usr/lib/libXm.so.2.0.1) ==23613==by 0x40AA0A6: XpmCreateImageFromData (in /usr/lib/libXm.so.2.0.1) ==23613==by 0x40AA342: XpmCreatePixmapFromData (in /usr/lib/libXm.so.2.0.1) ==23613==by 0x81C9E0E: gui_mch_init (gui_x11.c:1541) ==23613==by 0x81BA6F1: gui_init (gui.c:457) ==23613==by 0x81A56BD: set_termname (term.c:1845) ==23613==by 0x81A609D: termcapinit (term.c:2514) ==23613==by 0x81BA0BE: gui_start (gui.c:91) ==23613==by 0x80DED45: main (main.c:634) -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information,
Re: [patch] fixed compilation warnings + memory leak + crash (lesstif)
Dominique Pelle wrote: On Sun, Jun 8, 2008 at 2:25 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: Dominique Pelle wrote: On Sat, Jun 7, 2008 at 8:44 AM, Dominique Pelle wrote: Attached: - crash-os_unix.c.patch - leak-os_unix.c.patch I built the gui-motif, gui-athena and gui-gtk2 on Linux x86 and the crash in os_unix.c only happens with gui-motif (I'm using LessTif). So instead of doing #if 0 as in my previous patch, it should be better to do #ifndef FEAT_GUI_MOTIF. gui-athena shows errors with -DEXITFREE just a few lines below though: ==15738== Invalid read of size 4 ==15738==at 0x42CDEE7: XCloseDisplay (in /usr/lib/libX11.so.6.2.0) ==15738==by 0x8140419: mch_free_mem (os_unix.c:2900) ==15738==by 0x810A969: free_all_mem (misc2.c:1125) ==15738==by 0x8140573: mch_exit (os_unix.c:3012) ==15738==by 0x80DE4C8: getout (main.c:1342) ==15738==by 0x80A56C3: ex_quit_all (ex_docmd.c:6281) ==15738==by 0x809F8CB: do_one_cmd (ex_docmd.c:2623) ==15738==by 0x809D18C: do_cmdline (ex_docmd.c:1099) ==15738==by 0x812030E: nv_colon (normal.c:5179) ==15738==by 0x8119B88: normal_cmd (normal.c:1152) ==15738==by 0x80DE20A: main_loop (main.c:1181) ==15738==by 0x80DDD5A: main (main.c:940) ==15738== Address 0x44020cc is 148 bytes inside a block of size 1,340 free'd ==15738==at 0x402265C: free (vg_replace_malloc.c:323) ==15738==by 0x42E0F3E: _XFreeDisplayStructure (in /usr/lib/libX11.so.6.2.0) ==15738==by 0x42CDFC5: XCloseDisplay (in /usr/lib/libX11.so.6.2.0) ==15738==by 0x424EC49: (within /usr/lib/libXt.so.6.0.0) ==15738==by 0x424EE36: XtCloseDisplay (in /usr/lib/libXt.so.6.0.0) ==15738==by 0x424EE70: (within /usr/lib/libXt.so.6.0.0) ==15738==by 0x424F164: XtDestroyApplicationContext (in /usr/lib/libXt.so.6.0.0) ==15738==by 0x81403F4: mch_free_mem (os_unix.c:2896) ==15738==by 0x810A969: free_all_mem (misc2.c:1125) ==15738==by 0x8140573: mch_exit (os_unix.c:3012) ==15738==by 0x80DE4C8: getout (main.c:1342) ==15738==by 0x80A56C3: ex_quit_all (ex_docmd.c:6281) ==15738==by 0x809F8CB: do_one_cmd (ex_docmd.c:2623) ==15738==by 0x809D18C: do_cmdline (ex_docmd.c:1099) ==15738==by 0x812030E: nv_colon (normal.c:5179) ==15738==by 0x8119B88: normal_cmd (normal.c:1152) ==15738==by 0x80DE20A: main_loop (main.c:1181) ==15738==by 0x80DDD5A: main (main.c:940) os_unix.c: 2890 # if (defined(FEAT_X11) defined(FEAT_XCLIPBOARD)) || defined(PROTO) 2891 if (xterm_Shell != (Widget)0) 2892 XtDestroyWidget(xterm_Shell); 2893 if (xterm_dpy != NULL) 2894 XtCloseDisplay(xterm_dpy); 2895 if (app_context != (XtAppContext)NULL) !! 2896 XtDestroyApplicationContext(app_context); 2897 # endif 2898 # ifdef FEAT_X11 2899 if (x11_display != NULL x11_display != xterm_dpy) !! 2900 XCloseDisplay(x11_display); 2901 # endif Line 2900 is using memory which was freed at line 2896 according to valgrind. So it seems that XtDestroyApplicationContext(app_context) is also destroying x11_display. Attached patch fixes the error. Thanks. I wonder if we can use #ifndef LESSTIF_VERSION instead of FEAT_GUI_MOTIF. The other #if 0 suggests that Solaris also has this problem. But I'm not sure about this specific code, since it was added much later. Yes, #ifndef LESSTIF_VERSION is better than #ifndef FEAT_GUI_MOTIF. I tested it with both lesstif and Open Motif, it's fine. After the attached patch, neither lesstif, nor Open Motif access freed memory. Open Motif needs the same fix as for athena gui i.e. set x11_display to NULL after 'XtDestroyApplicationContext(app_context);' since it seems to take care of already calling 'XCloseDisplay(x11_display)'. Lesstif and Open Motif also use uninitialized memory but I assume that's a problem in those libs and not with Vim. There are several things not freed with all GUIs (athena, open motif lesstif, gtk2, gnome2) when exiting even with -DEXITFREE but that's not a major problem I think. I fixed at least the following leak which happens at least for Motif and athena gui (patch: leak-gui_x11.c). ==23613== 32 bytes in 1 blocks are definitely lost in loss record 34 of 126 ==23613==at 0x4022AB8: malloc (vg_replace_malloc.c:207) ==23613==by 0x40A8C08: xpmParseDataAndCreate (in /usr/lib/libXm.so.2.0.1) ==23613==by 0x40AA0A6: XpmCreateImageFromData (in /usr/lib/libXm.so.2.0.1) ==23613==by 0x40AA342: XpmCreatePixmapFromData (in /usr/lib/libXm.so.2.0.1) ==23613==by 0x81C9E0E: gui_mch_init (gui_x11.c:1541) ==23613==by 0x81BA6F1: gui_init (gui.c:457) ==23613==by 0x81A56BD: set_termname (term.c:1845) ==23613==by 0x81A609D: termcapinit (term.c:2514) ==23613==by 0x81BA0BE: gui_start (gui.c:91) ==23613==by 0x80DED45: main (main.c:634)
