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>
