Re: [Valgrind-users] Can't see the actual vars

[John R. <jr...@bi...>]

> ==3232== Syscall param stat64(file_name) points to uninitialised byte(s)

file_name is the first (leftmost) parameter.

> ==3232==    at 0x49FD6B8: _xstat (xstat.c:48)
> ==3232==    by 0x41F23: stat (stat.c:51)
> ==3232==    by 0x1EC93: getList (util.c:1379)

 > Looking at line 1379 from util.c:
 > if (!stat(listfile, &statbuf))

> ==3232==    by 0x18E0F: _get_var (ngr.c:3868)
> ==3232==    by 0x19F33: get_var (ngr.c:4049)
> ==3232==    by 0xBB4F: main (daemon.c:346)
> ==3232==  Address 0x7d87ba8c is on thread 1's stack
> ==3232==  in frame #2, created by getList (util.c:1300)
> ==3232==  Uninitialised value was created by a stack allocation
> ==3232==    at 0x1E55C: getList (util.c:1300)

> listfile does exist.

What is the declaration of listfile?  Is it an array, a pointer, ...?
It would be helpful to print its value:
     fprintf(stderr, "\nlistfile='%s'\n", listfile);
just before the stat() call.

> statbuf however, is simply defined as: struct stat statbuf;
> It's not initialized by memset or something, is that what valgrind complains about?

No; the first line of the complaint indicates that the complaint
is about the file_name, the first parameter, which is read by stat().
The documentation (run the shell command "man 2 stat") explains that
the second argument is output-only.  The operating system kernel
writes to [nearly] all the statbuf, and reads none of it.

If the original presentation captures all the important information,
then it will be easy to construct a small stand-alone test case
that triggers the complaint in question.  Please try that.