Thanks for the reply, David.
I fully agree and believe me, the systems I'm in charge of in our code base do
not have a single issue like that. That's a lesson I learned during my studies
more than 20 years ago already.
Unfortunately, default initializing every trivial and non-trivial field isn't
doable as that would be of rather large refactoring nature and is outside of my
current task and way too risky for the stage, we're in. Again, I do agree
otherwise though.
Thanks,
Thomas
________________________________
From: David Chapman <dcchap...@acm.org>
Sent: Saturday, June 15, 2024 10:41 PM
To: Thomas Wollenzin <wolle...@msn.com>; valgrind-users@lists.sourceforge.net
<valgrind-users@lists.sourceforge.net>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move
depends on uninitialised value(s)'
On 6/15/2024 10:38 AM, Thomas Wollenzin wrote:
Hi,
I'm not too familiar with valgrind yet so excuse a potentially dumb question.
I'm trying to fix an issue in our code base that valgrind reported as
'Conditional jump or move depends on uninitialised value(s)'. In particular I
have a hard time understanding what the exact item is that's being seen as
uninitialised. I can't share code as it's very complex and non-public.
What happens is that a rather large class is allocated via operator new which
comes with tons of subsequent data. Unfortunately, a lot of that data isn't
default initialized so it's rather impossible to go by trial and error.
Valgrind does report the place where the condition is but it's a super busy
loop that works on tons of templated data.
Is there a way to have Valgrind tell me what type exactly has the uninitialised
field or at best break at the time this exact incident occurs?
Thanks,
Thomas
I have fixed so many bugs by initializing seemingly harmless variables that I
now initialize all variables and all data structure fields, even if only to
nullptr. Valgrind found one use of an uninitialized variable; you probably
have many more that didn't show up in this run.
My advice is to make some guesses and initialize the most likely suspects until
the problem goes away. You might call that "trial and error", but
initialization fixes bugs; it does not create new ones.
Then schedule a pass to go over all your code and initialize everything else.
You won't regret it.
--
David Chapman dcchap...@acm.org<mailto:dcchap...@acm.org>
Chapman Consulting -- San Jose, CA
EDA Software Developer, Expert Witness
www.chapman-consulting-sj.com<http://www.chapman-consulting-sj.com>
2018-2019 Chair, IEEE Consultants' Network of Silicon Valley
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
