==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.
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
