Traceback from valgrind when running a vim9 script

[Yegappan Lakshmanan]

Hi,

When running Vim under valgrind, if the following Vim9 script

is sourced:

=================================

vim9script
def Func1(pat_arg: string)
  echo pat_arg
enddef
Func1('*.c')

=================================

The following traceback is reported:

==33841== Conditional jump or move depends on uninitialised value(s)
==33841==    at 0x5D7E47: typval2type (vim9type.c:312)
==33841==    by 0x5D874F: check_typval_type (vim9type.c:354)
==33841==    by 0x5D2927: call_def_function (vim9execute.c:795)
==33841==    by 0x5C3059: call_user_func (userfunc.c:1319)
==33841==    by 0x5C36D3: call_user_func_check (userfunc.c:1711)
==33841==    by 0x5C3B5F: call_func (userfunc.c:2179)
==33841==    by 0x5C3FD2: get_func_tv (userfunc.c:690)
==33841==    by 0x45198B: eval_func (eval.c:1900)
==33841==    by 0x455F9A: eval7 (eval.c:3256)
==33841==    by 0x456440: eval6 (eval.c:2895)
==33841==    by 0x456440: eval5 (eval.c:2670)
==33841==    by 0x4569BB: eval4 (eval.c:2532)
==33841==    by 0x456FAE: eval3 (eval.c:2385)
==33841==    by 0x456FAE: eval2 (eval.c:2251)
==33841==    by 0x456FAE: eval1 (eval.c:2109)

This is seen with Vim 8.2.1666.

- Yegappan

[Bram Moolenaar]

I have noticed this in a few places. The problem is that often a
typval_T is passed to the evaluation functions and only v_type is
initialized. Or nothing at all. Then when accessing any of the fields,
possibly when evaluation failed or didn't set v_lock, a field is read
that wasn't initialized.

It might be the best to initialize rettv in eval0(). It might be a bit
of extra work in case evaluation fails, but that's not relevant.

--
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke
Any sufficiently advanced bug is indistinguishable from a feature.
Rich Kulawiec

/// Bram Moolenaar -- Br...@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 ///

[Dominique Pellé]

I can reproduce it with the latest vim-8.2.1671.

For uninitialized valgrind memory error, it's useful to
use the --track-origins=yes valgrind option. It gives
extra information.

$ valgrind --num-callers=50 --track-origins=yes --leak-check=full
./vim --clean -c 'so foo.vim' 2> log

==24910== Memcheck, a memory error detector
==24910== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24910== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info
==24910== Command: ./vim --clean -c so\ bug-vim9.vim
==24910==
==24910== Conditional jump or move depends on uninitialised value(s)
==24910== at 0x38D101: typval2type (vim9type.c:312)
==24910== by 0x38E186: check_typval_type (vim9type.c:354)
==24910== by 0x386BD3: call_def_function (vim9execute.c:795)
==24910== by 0x36BAF9: call_user_func (userfunc.c:1328)
==24910== by 0x36D6D3: call_user_func_check (userfunc.c:1720)
==24910== by 0x36D6D3: call_user_func_check (userfunc.c:1684)
==24910== by 0x36E67A: call_func (userfunc.c:2188)
==24910== by 0x36EC5E: get_func_tv (userfunc.c:690)
==24910== by 0x1926C1: eval_func (eval.c:1900)
==24910== by 0x1979B7: eval7 (eval.c:3256)
==24910== by 0x19875D: eval6 (eval.c:2895)
==24910== by 0x19875D: eval5 (eval.c:2670)
==24910== by 0x19875D: eval4 (eval.c:2532)
==24910== by 0x198E81: eval3 (eval.c:2385)
==24910== by 0x198E81: eval2 (eval.c:2251)
==24910== by 0x198E81: eval1 (eval.c:2109)
==24910== by 0x19A102: eval0 (eval.c:2062)
==24910== by 0x1D1DD3: ex_eval (ex_eval.c:902)
==24910== by 0x1CB65F: do_one_cmd (ex_docmd.c:2537)
==24910== by 0x1CC8CC: do_cmdline (ex_docmd.c:983)
==24910== by 0x2EC584: do_source (scriptfile.c:1432)
==24910== by 0x2ECE8E: cmd_source (scriptfile.c:971)
==24910== by 0x2ECE8E: ex_source (scriptfile.c:997)
==24910== by 0x1CB65F: do_one_cmd (ex_docmd.c:2537)
==24910== by 0x1CC8CC: do_cmdline (ex_docmd.c:983)
==24910== by 0x3E8889: exe_commands (main.c:3051)
==24910== by 0x3E8889: vim_main2 (main.c:763)
==24910== by 0x7100B96: (below main) (libc-start.c:310)
==24910== Uninitialised value was created by a stack allocation
==24910== at 0x36E8B0: get_func_tv (userfunc.c:621)

So now we know the uninitialized variable is
local to get_func_tv() in userfunc.c:621.

It's the argvars local variable which is uninitialized.

The following patch avoids the warning, but I don't
know if it's just hiding a bug:

diff --git a/src/userfunc.c b/src/userfunc.c
index d28125fdd..afd6f9c88 100644
--- a/src/userfunc.c
+++ b/src/userfunc.c
@@ -621,7 +621,7 @@ get_func_tv(
{
char_u *argp;
int ret = OK;
- typval_T argvars[MAX_FUNC_ARGS + 1]; // vars for arguments
+ typval_T argvars[MAX_FUNC_ARGS + 1] = {}; // vars for arguments
int argcount = 0; // number of arguments found
int vim9script = in_vim9script();