library: address an 'uninitialised value' VALGRIND bug
Thanks to valgrind and his --track-origins=yes option,
the problem and solution was suggested as shown below.
[ and it was created in that commit referenced below ]
But, after attacking this problem by adding a memset()
call in pids.c, a 2nd valgrind oops, also shown below,
was encountered. The dynamically acquired 'cmd' again!
[ might help to explain why changes appear excessive ]
Reference(s):
. 1st valgrind discovery
==11111== Conditional jump or move depends on uninitialised value(s)
==11111== at 0x13425D: stat2proc (readproc.c:582)
==11111== by 0x137436: look_up_our_self (readproc.c:1613)
==11111== by 0x132196: fatal_proc_unmounted (pids.c:1388)
==11111== by 0x11BA4D: before (top.c:3580)
==11111== by 0x127E10: main (top.c:7173)
==11111== Uninitialised value was created by a stack allocation
==11111== at 0x132165: fatal_proc_unmounted (pids.c:1381)
. Jul, 2022 - fatal_proc_unmounted refactored
commit 52bd019d8c
. 2nd valgrind discovery
==22222== 16 bytes in 1 blocks are definitely lost
==22222== by 0x4A0E60E: strdup (strdup.c:42)
==22222== by 0x133D00: stat2proc (readproc.c:587)
==22222== by 0x136E67: look_up_our_self (readproc.c:1613)
==22222== by 0x131BC7: fatal_proc_unmounted (pids.c:1390)
==22222== by 0x11B7C6: before (top.c:3580)
==22222== by 0x127828: main (top.c:7173)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit is contained in:
@ -281,7 +281,7 @@ PROCTAB *openproc(unsigned flags, ... /* pid_t *| uid_t *| dev_t *| char *[, int
|
||||
// with the previous process or thread.
|
||||
proc_t *readproc(PROCTAB *__restrict const PT, proc_t *__restrict p);
|
||||
proc_t *readeither(PROCTAB *__restrict const PT, proc_t *__restrict x);
|
||||
int look_up_our_self(proc_t *p);
|
||||
int look_up_our_self(void);
|
||||
void closeproc(PROCTAB *PT);
|
||||
char **vectorize_this_str(const char *src);
|
||||
|
||||
|
Reference in New Issue
Block a user