On 15-06-24 17:38, 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?
You seem a bit confused about C++ initialization. For all the gory
details see https://www.cppstories.com/2022/cpp-init-book/ or for free
https://en.cppreference.com/w/cpp/language/initialization
"default initialization" for builtin types means do nothing, i.e., leave
the memory uninitialized. You probably mean "value initialized".
As Nick already suggested, start with --track-origins=yes.
That should give you a starting point and an end point for the error.
The real problem is that the uninitizedness state is transitive which
means that the variables that are uninitialized may go through various
phases of being uninitialized and initialized before reaching the
conditional expression that triggers the error.
There are two things that you can do to track down the error in the code.
As John suggested, try vgdb. Set breakpoints in the code and then make
heavy use of the "monitor xb" (or just "mc xb" if your gdb isn't too
old) to 'examine bytes' for initializedness. You may have to debug
multiple times as you work back to the source of the error. Valgrind
doesn't support time travel debugging.
As an alternative (if your build times are short or it's difficult to
debug the code with gdb) then you can 'instrument' your code with
conditions. For instance, if you think the variable "widget" is the
culprit, then somewhere before the reported error add something like
if (widget == 0)
{
std::cout << "widget condition true\n";
}
Then repeat the cycle of adding such conditions, rebuilding and
rerunning until you find the problem.
As a quick fix, try using -ftrivial-auto-var-init=zero if your compiler
supports it. It will have a small performance overhead but it's close to
100% backwards compatible.
A+
Paul
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
