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:3333)
==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(&globvarht);
+ saved_string = NULL;
/* autoloaded script names */
ga_clear_strings(&ga_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 -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
