|
From: Reinoud K. <rei...@gm...> - 2019-07-22 20:51:49
|
Hello Everyone, I am seeing messages like this: --3232-- REDIR: 0x49bf990 (libc.so.6:strncat) redirected to 0x482d71c (strncat) ==3232== Syscall param stat64(file_name) points to uninitialised byte(s) ==3232== at 0x49FD6B8: _xstat (xstat.c:48) ==3232== by 0x41F23: stat (stat.c:51) ==3232== by 0x1EC93: getList (util.c:1379) ==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) Looking at line 1379 from util.c: if (!stat(listfile, &statbuf)) listfile does exist. statbuf however, is simply defined as: struct stat statbuf; It's not initialized by memset or something, is that what valgrind complains about? Thanks, Reinoud. |
|
From: John R. <jr...@bi...> - 2019-07-23 01:27:21
|
> ==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.
|