Dominique Pellé wrote:
> > I still see leaks in valgrind.test_alot, Most of them come from
> > the child process after fork() because we don't call free_all_mem()
> > in the child process. But 2 leaks (below) come from the parent process.
> > Perhaps those 2 leaks need to be looked at. I will investigate them
> > this weekend:
>
> I can reproduce one of the leaks with this minimal case:
>
> $ cat leak.vim
> let s:meow = {}
> function s:meow.bite(...)
> endfunction
> call timer_start(50, s:meow.bite)
>
> $ valgrind --num-callers=50 --leak-check=yes \
> ./vim -u NONE -N -S leak.vim -c q 2> log
>
> And log file shows this leak:
>
> ==3006== Memcheck, a memory error detector
> ==3006== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==3006== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==3006== Command: ./vim -u NONE -N -S leak.vim -c q
> ==3006==
> ==3006==
> ==3006== HEAP SUMMARY:
> ==3006== in use at exit: 104,857 bytes in 429 blocks
> ==3006== total heap usage: 7,613 allocs, 7,184 frees, 1,056,377
> bytes allocated
> ==3006==
> ==3006== 2 bytes in 1 blocks are definitely lost in loss record 2 of 133
> ==3006== at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
> ==3006== by 0x4E4735: lalloc (misc2.c:920)
> ==3006== by 0x4E4602: alloc (misc2.c:818)
> ==3006== by 0x4E4BA2: vim_strsave (misc2.c:1256)
> ==3006== by 0x453B49: f_timer_start (evalfunc.c:11934)
> ==3006== by 0x44110A: call_internal_func (evalfunc.c:982)
> ==3006== by 0x5D1605: call_func (userfunc.c:1399)
> ==3006== by 0x5CF418: get_func_tv (userfunc.c:512)
> ==3006== by 0x5D5093: ex_call (userfunc.c:2961)
> ==3006== by 0x46FCC3: do_one_cmd (ex_docmd.c:2925)
> ==3006== by 0x46C9AF: do_cmdline (ex_docmd.c:1110)
> ==3006== by 0x46A671: do_source (ex_cmds2.c:3983)
> ==3006== by 0x469C83: cmd_source (ex_cmds2.c:3596)
> ==3006== by 0x469BD5: ex_source (ex_cmds2.c:3571)
> ==3006== by 0x46FCC3: do_one_cmd (ex_docmd.c:2925)
> ==3006== by 0x46C9AF: do_cmdline (ex_docmd.c:1110)
> ==3006== by 0x46BFEB: do_cmdline_cmd (ex_docmd.c:715)
> ==3006== by 0x5F71D9: exe_commands (main.c:2895)
> ==3006== by 0x5F4595: main (main.c:780)
>
> Repeating the line "call timer_start(50, s:meow.bite)" n times
> in leak.vim results in n leaks.
>
> I tried this patch:
>
> diff --git a/src/evalfunc.c b/src/evalfunc.c
> index f665842..0d5e209 100644
> --- a/src/evalfunc.c
> +++ b/src/evalfunc.c
> @@ -11880,14 +11880,14 @@ get_callback(typval_T *arg, partial_T **pp)
> }
>
> /*
> - * Unref/free "callback" and "partial" retured by get_callback().
> + * Unref/free "callback" and "partial" returned by get_callback().
> */
> void
> free_callback(char_u *callback, partial_T *partial)
> {
> if (partial != NULL)
> partial_unref(partial);
> - else if (callback != NULL)
> + if (callback != NULL)
> {
> func_unref(callback);
> vim_free(callback);
>
> It fixes the leak in this case, but it's not correct as it causes
> use of freed memory in other tests. I don't see yet how to fix it.
Thanks for investigating. I recognize the problem. The callback should
not be allocated when using a partial. Now that I know where to look I
know how to fix it.
I also notice that exiting early reports leaks, probably because the
timer is still pending. Need to find a way to free them, since they are
still referenced.
--
No children may attend school with their breath smelling of "wild onions."
[real standing law in West Virginia, United States of America]
/// 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.
