Thanks for the reply, Paul. What I mean by saying "default initialization" is the process of constructing classes/structs through any constructor in C++ where devs forgot to initialize fields to some value.
Thanks for your suggestions, I'll give them a try. Regards, Thomas ________________________________ From: Paul Floyd via Valgrind-users <valgrind-users@lists.sourceforge.net> Sent: Sunday, June 16, 2024 6:57 AM To: 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 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
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
