valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Mark W. <ma...@kl...>]

On Wed, Jun 19, 2024 at 08:07:09PM +0000, Paul Floyd via Valgrind-users wrote:
> On 19-06-24 08:15, Thomas Wollenzin wrote:
> >Thanks for the hint, Sean.
> >While that might work perfectly fine, I'm personally not a big fan
> >of these types of tools. They're fine for proofing a theory but
> >shouldn't be used to 'cover up' developer mistakes. Code should be
> >written as solidly as possible.
> 
> Read more about the proposal here
> 
> https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2022/p2723r0.html
> 
> I'm fairly certain that things like this will be part of C++ in the
> next 5 years or so. That won't be using this option directly, more
> likely part of a 'profiles' feature.

Interesting proposal. I notice they mention that valgrind memcheck
will no longer be able to detect use of uninitialized variables
anymore:

  Making all automatic variables explicitly zero means that developers
  will come to rely on it. The current status-quo forces developers to
  express intent, and new code might decide not to do so and simply
  use the zero that they know to be there. This would then make it
  impossible to distinguish "purposeful use of the uninitialized zero"
  from "accidental use of the uninitialized zero". Tools such as
  memory sanitizers and valgrind would therefore be unable to diagnose
  correctness issues (but we would have removed the security
  issues). It should still be best practice to only assign a value to
  a variable when this value is meaningful, and only use an
  "uninitialized" value when meaning has been give to it.

I wonder if there would be some implementation so that we can detect
the zeroing is part of this automatic variable initialization and then
still mark the storage as not defined.

But I cannot think of one. It seems optimizatin of the code will make
it indistinquisable from explicit initialization.

Cheers,

Mark

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Paul F. <pj...@wa...>]

On 19-06-24 08:15, Thomas Wollenzin wrote:
> Thanks for the hint, Sean.
> While that might work perfectly fine, I'm personally not a big fan of 
> these types of tools. They're fine for proofing a theory but shouldn't 
> be used to 'cover up' developer mistakes. Code should be written as 
> solidly as possible.


Read more about the proposal here

https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2022/p2723r0.html

I'm fairly certain that things like this will be part of C++ in the next 
5 years or so. That won't be using this option directly, more likely 
part of a 'profiles' feature.


A+
Paul

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

Absolutely, thanks for the reply.

Thomas

________________________________
From: Sean McBride <se...@ro...>
Sent: Wednesday, June 19, 2024 5:27 PM
To: Thomas Wollenzin <wol...@ms...>
Cc: David Chapman <dcc...@ac...>; val...@li... <val...@li...>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

On 19 Jun 2024, at 4:15, Thomas Wollenzin wrote:

> While that might work perfectly fine, I'm personally not a big fan of these types of tools. They're fine for proofing a theory but shouldn't be used to 'cover up' developer mistakes. Code should be written as solidly as possible.

Not to get too OT here, but they aren't mutually exclusive.

You can write your code solidly, and use valgrind, ASan, and -ftrivial-auto-var-init=pattern in your debug builds, and fix all issues they find.

Simultaneously, you can also use -ftrivial-auto-var-init=zero in your release builds, which BTW Apple and Microsoft reportedly do, as it provides security benefits for a tiny performance hit. (As discussed in that thread I linked.)

Sean

________________________________
From: Sean McBride <se...@ro...>
Sent: Wednesday, June 19, 2024 5:27 PM
To: Thomas Wollenzin <wol...@ms...>
Cc: David Chapman <dcc...@ac...>; val...@li... <val...@li...>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

On 19 Jun 2024, at 4:15, Thomas Wollenzin wrote:

> While that might work perfectly fine, I'm personally not a big fan of these types of tools. They're fine for proofing a theory but shouldn't be used to 'cover up' developer mistakes. Code should be written as solidly as possible.

Not to get too OT here, but they aren't mutually exclusive.

You can write your code solidly, and use valgrind, ASan, and -ftrivial-auto-var-init=pattern in your debug builds, and fix all issues they find.

Simultaneously, you can also use -ftrivial-auto-var-init=zero in your release builds, which BTW Apple and Microsoft reportedly do, as it provides security benefits for a tiny performance hit. (As discussed in that thread I linked.)

Sean

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Sean M. <se...@ro...>]

On 19 Jun 2024, at 4:15, Thomas Wollenzin wrote:

> While that might work perfectly fine, I'm personally not a big fan of these types of tools. They're fine for proofing a theory but shouldn't be used to 'cover up' developer mistakes. Code should be written as solidly as possible.

Not to get too OT here, but they aren't mutually exclusive.

You can write your code solidly, and use valgrind, ASan, and -ftrivial-auto-var-init=pattern in your debug builds, and fix all issues they find.

Simultaneously, you can also use -ftrivial-auto-var-init=zero in your release builds, which BTW Apple and Microsoft reportedly do, as it provides security benefits for a tiny performance hit. (As discussed in that thread I linked.)

Sean

Re: [Valgrind-users] question regarding mismatching free/delete

[Thomas W. <wol...@ms...>]

Thanks for the reply, Paul. You're right. It's about replacement functions instead of overloads.

The VG run was done in an optimized environment and the functions got indeed inlined.

Cheers,
Thomas

________________________________
From: Paul Floyd via Valgrind-users <val...@li...>
Sent: Monday, June 17, 2024 1:18 PM
To: val...@li... <val...@li...>
Subject: Re: [Valgrind-users] question regarding mismatching free/delete



On 17-06-24 08:45, Thomas Wollenzin wrote:
> Hi,
>
> I have a questing regarding Valgrind report 'Mismatched free() / delete
> / delete []'.
>
> I understand that Valgrind is redirecting calls to new/delete and so on
> to its own. On the allocation side I see:
>
>     operator new(unsigned long) (vg_replace_malloc.c:487)
>
>
> on the deallocation side
>
>     free (vg_replace_malloc.c:989)
>
> Our new/delete operators are overloaded and call effectively malloc/free
> at some point.
> Could it be that Valgrind can get confused and not resolve the
> overloaded operators correctly?


By coincidence I updated the FAQ on this subject yesterday. See

https://valgrind.org/docs/manual/faq.html#faq.mismatches

It doesn't sound like you are using tcmalloc.

I assume that you mean "replacement new/delete", not overload.
See https://en.cppreference.com/w/cpp/memory/new/operator_new
("replaceable allocation functions").
If you really are adding a new overload to the existing set then
I would expect Memcheck to not be able to redirect your overloads.

If (more likely) you are replacing one of the existing set of
standard overloads then are you ensuring that they don't get
inlined? (See the FAQ).

A+
Paul


_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

________________________________
From: Paul Floyd via Valgrind-users <val...@li...>
Sent: Monday, June 17, 2024 1:18 PM
To: val...@li... <val...@li...>
Subject: Re: [Valgrind-users] question regarding mismatching free/delete



On 17-06-24 08:45, Thomas Wollenzin wrote:
> Hi,
>
> I have a questing regarding Valgrind report 'Mismatched free() / delete
> / delete []'.
>
> I understand that Valgrind is redirecting calls to new/delete and so on
> to its own. On the allocation side I see:
>
>     operator new(unsigned long) (vg_replace_malloc.c:487)
>
>
> on the deallocation side
>
>     free (vg_replace_malloc.c:989)
>
> Our new/delete operators are overloaded and call effectively malloc/free
> at some point.
> Could it be that Valgrind can get confused and not resolve the
> overloaded operators correctly?


By coincidence I updated the FAQ on this subject yesterday. See

https://valgrind.org/docs/manual/faq.html#faq.mismatches

It doesn't sound like you are using tcmalloc.

I assume that you mean "replacement new/delete", not overload.
See https://en.cppreference.com/w/cpp/memory/new/operator_new
("replaceable allocation functions").
If you really are adding a new overload to the existing set then
I would expect Memcheck to not be able to redirect your overloads.

If (more likely) you are replacing one of the existing set of
standard overloads then are you ensuring that they don't get
inlined? (See the FAQ).

A+
Paul


_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

Thanks for the hint, Sean.
While that might work perfectly fine, I'm personally not a big fan of these types of tools. They're fine for proofing a theory but shouldn't be used to 'cover up' developer mistakes. Code should be written as solidly as possible.

Cheers,
Thomas

________________________________
From: Sean McBride <se...@ro...>
Sent: Monday, June 17, 2024 6:08 PM
To: David Chapman <dcc...@ac...>
Cc: Thomas Wollenzin <wol...@ms...>; val...@li... <val...@li...>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

On 15 Jun 2024, at 16:41, David Chapman via Valgrind-users wrote:

> Then schedule a pass to go over all your code and initialize everything else.  You won't regret it.

and/or build with -ftrivial-auto-var-init=zero

See also:
https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/

Sean

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Sean M. <se...@ro...>]

On 15 Jun 2024, at 16:41, David Chapman via Valgrind-users wrote:

> Then schedule a pass to go over all your code and initialize everything else.  You won't regret it.

and/or build with -ftrivial-auto-var-init=zero

See also:
https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/

Sean

Re: [Valgrind-users] question regarding mismatching free/delete

[Paul F. <pj...@wa...>]

On 17-06-24 08:45, Thomas Wollenzin wrote:
> Hi,
> 
> I have a questing regarding Valgrind report 'Mismatched free() / delete 
> / delete []'.
> 
> I understand that Valgrind is redirecting calls to new/delete and so on 
> to its own. On the allocation side I see:
> 
>     operator new(unsigned long) (vg_replace_malloc.c:487)
> 
> 
> on the deallocation side
> 
>     free (vg_replace_malloc.c:989)
> 
> Our new/delete operators are overloaded and call effectively malloc/free 
> at some point.
> Could it be that Valgrind can get confused and not resolve the 
> overloaded operators correctly?


By coincidence I updated the FAQ on this subject yesterday. See

https://valgrind.org/docs/manual/faq.html#faq.mismatches

It doesn't sound like you are using tcmalloc.

I assume that you mean "replacement new/delete", not overload.
See https://en.cppreference.com/w/cpp/memory/new/operator_new
("replaceable allocation functions").
If you really are adding a new overload to the existing set then
I would expect Memcheck to not be able to redirect your overloads.

If (more likely) you are replacing one of the existing set of
standard overloads then are you ensuring that they don't get
inlined? (See the FAQ).

A+
Paul

Re: [Valgrind-users] question regarding mismatching free/delete

[Thomas W. <wol...@ms...>]

Thanks for the reply Julian.

Does that mean that you fully disable Valgrind to report on any potential mismatching frees? Isn't that robbing you of the ability to get at least notified about potential issues to that regard?

Cheers,
Thomas
________________________________
From: Julian Seward <jse...@gm...>
Sent: Monday, June 17, 2024 11:53 AM
To: Thomas Wollenzin <wol...@ms...>; val...@li... <val...@li...>
Subject: Re: [Valgrind-users] question regarding mismatching free/delete

On 17/06/2024 10:45, Thomas Wollenzin wrote:

> Could it be that Valgrind can get confused and not resolve the overloaded operators correctly?

This can happen as a result of "differential inlining".  What I mean is, you
have `new` calls `malloc` and `delete` calls `free`, and the definitions of
`malloc` and `free` are visible to the compiler (maybe you defined your own
wrappers for them).  Then, if `malloc` is inlined into `new` but `free` is
not inlined into `delete`, or vice versa, then you will get these reports.

I have this a lot when running Firefox on Valgrind, so I run with
--show-mismatched-frees=no.

J

Re: [Valgrind-users] question regarding mismatching free/delete

[Julian S. <jse...@gm...>]

On 17/06/2024 10:45, Thomas Wollenzin wrote:

> Could it be that Valgrind can get confused and not resolve the overloaded operators correctly?

This can happen as a result of "differential inlining".  What I mean is, you
have `new` calls `malloc` and `delete` calls `free`, and the definitions of
`malloc` and `free` are visible to the compiler (maybe you defined your own
wrappers for them).  Then, if `malloc` is inlined into `new` but `free` is
not inlined into `delete`, or vice versa, then you will get these reports.

I have this a lot when running Firefox on Valgrind, so I run with
--show-mismatched-frees=no.

J

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

Thanks for following up and correcting a typo!

Cheers,
Thomas

________________________________
From: John Reiser <jr...@bi...>
Sent: Sunday, June 16, 2024 1:59 AM
To: val...@li... <val...@li...>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

> Also note that malloc()+memset() can choose byte values other than 0;
.
A value such as 0xA5 can increase visual effectiveness of memory dumps.

> Also note that there is a feature of glibc malloc() such that the shell
> environment variable MALLOC_PERTURN_=NNN (note the trailing underscore)

MALLOC_PERTURB_



_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] question regarding mismatching free/delete

[Thomas W. <wol...@ms...>]

Hi,

I have a questing regarding Valgrind report 'Mismatched free() / delete / delete []'.

I understand that Valgrind is redirecting calls to new/delete and so on to its own. On the allocation side I see:

operator new(unsigned long) (vg_replace_malloc.c:487)

on the deallocation side

free (vg_replace_malloc.c:989)
Our new/delete operators are overloaded and call effectively malloc/free at some point.
Could it be that Valgrind can get confused and not resolve the overloaded operators correctly?

Thanks,
Thomas

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

This indeed seems very useful. Thanks for making me aware of this tool, John.

Cheers,
Thomas

________________________________
From: John Reiser <jr...@bi...>
Sent: Sunday, June 16, 2024 10:03 PM
To: val...@li... <val...@li...>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

> 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.

The "ultimate hammer" or "magic wand" is 'rr', which is
"Record and Replay".  By using it you can execute *backwards*,
that is "back up" from the point of error to as far back
as you want, examining memory as you go; or even setting
breakpoints or watchpoints to see when (in the past!) state changed.
See  https://rr-project.org ; also search the 'net for
"rr record replay".

You'll have to learn this new style of debugging,
and you will need a lot of disk space: 100GB is typical.
But you *will* find the bug!


_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

Thanks for the reply Nick.

I do have --track-origins=yes enabled, always. This way I know where the object in question is allocated and where the uninitialized access occurs. It's still insufficient unfortunately as it doesn't reveal the exact involved actors.

Thanks,
Thomas

________________________________
From: Nicholas Nethercote <n.n...@gm...>
Sent: Sunday, June 16, 2024 1:13 AM
To: Thomas Wollenzin <wol...@ms...>
Cc: val...@li... <val...@li...>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

Hi,

Re-run with the --track-origins=yes flag enabled and it will give you more detail about where the uninitialized value comes from. (That option isn't on by default because it makes Valgrind run more slowly.)

Nick

On Sun, 16 Jun 2024 at 06:13, Thomas Wollenzin <wol...@ms...<mailto:wol...@ms...>> 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

_______________________________________________
Valgrind-users mailing list
Val...@li...<mailto:Val...@li...>
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

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 <dcc...@ac...>
Sent: Saturday, June 15, 2024 10:41 PM
To: Thomas Wollenzin <wol...@ms...>; val...@li... <val...@li...>
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      dcc...@ac...<mailto:dcc...@ac...>
    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

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

Thanks for sharing a bit of history regarding my inquiry, John. That's always welcome as it helps drawing a more complete picture.

I'll look into some of your suggestions.

Thanks,
Thomas
________________________________
From: John Reiser <jr...@bi...>
Sent: Sunday, June 16, 2024 1:05 AM
To: val...@li... <val...@li...>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

> 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?

For over two decades I have asked for a mode which complains at the
instant that an uninit bit is fetched from memory.  The usual excuse
of valgrind implementors is that uninit padding and alignment bytes,
plus compilers which can "over fetch", cause too many "false positive"
complaints.  But when I need this feature, then I *really* need it,
and I am willing to find the needle in the haystack.  Alas, valgrind
does not have such a mode.

For the case which you describe:
    a rather large class is allocated via operator new
    which comes with tons of subsequent data ... isn't
    default initialized
have you considered defining a function which calls calloc()
of the sizeof the class, then "placement new" to perform the
construction into that space?
Note that this hides real programming errors of type "forgot to
initialize"; and a few times a year it is very possible
that discovering such errors may reveal a real gap in your
overall logic.
Also note that malloc()+memset() can choose byte values other than 0;
and for floating point then bytes such as 0xFF (which causes NaN)
might be preferable because it effectively re-enables some checking
for uninit.
Also note that there is a feature of glibc malloc() such that the shell
environment variable MALLOC_PERTURN_=NNN (note the trailing underscore)
will do this for *all* calls to malloc().

For cases when the uninit is in not all the bits of a variable,
then you can use valgrind 'monitor' commands in a gdbserver to print
the status of each bit.  See the manual section 3.2: Debugging your
program using Valgrind gdbserver and GDB.



_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

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 <val...@li...>
Sent: Sunday, June 16, 2024 6:57 AM
To: val...@li... <val...@li...>
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
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[John R. <jr...@bi...>]

> 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.

The "ultimate hammer" or "magic wand" is 'rr', which is
"Record and Replay".  By using it you can execute *backwards*,
that is "back up" from the point of error to as far back
as you want, examining memory as you go; or even setting
breakpoints or watchpoints to see when (in the past!) state changed.
See  https://rr-project.org ; also search the 'net for
"rr record replay".

You'll have to learn this new style of debugging,
and you will need a lot of disk space: 100GB is typical.
But you *will* find the bug!

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Julian S. <jse...@gm...>]

> As Nick already suggested, start with --track-origins=yes.

That should be the first thing to try.

> 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";
> }

Agreed; this is useful if --track-origins=yes doesn't help.

A somewhat more general way to force an immediate test is

   #include <valgrind/memcheck.h>
   ...
   VALGRIND_CHECK_MEM_IS_DEFINED(pointer, length)   or
   VALGRIND_CHECK_VALUE_IS_DEFINED(lvalue)

I've found those two to be useful in tracking down difficult errors.

J

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Paul F. <pj...@wa...>]

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

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[John R. <jr...@bi...>]

> Also note that malloc()+memset() can choose byte values other than 0;
.
A value such as 0xA5 can increase visual effectiveness of memory dumps.

> Also note that there is a feature of glibc malloc() such that the shell
> environment variable MALLOC_PERTURN_=NNN (note the trailing underscore)

MALLOC_PERTURB_

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[John R. <jr...@bi...>]

> 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?

For over two decades I have asked for a mode which complains at the
instant that an uninit bit is fetched from memory.  The usual excuse
of valgrind implementors is that uninit padding and alignment bytes,
plus compilers which can "over fetch", cause too many "false positive" 
complaints.  But when I need this feature, then I *really* need it,
and I am willing to find the needle in the haystack.  Alas, valgrind
does not have such a mode.

For the case which you describe:
    a rather large class is allocated via operator new
    which comes with tons of subsequent data ... isn't
    default initialized
have you considered defining a function which calls calloc()
of the sizeof the class, then "placement new" to perform the 
construction into that space?
Note that this hides real programming errors of type "forgot to
initialize"; and a few times a year it is very possible
that discovering such errors may reveal a real gap in your
overall logic.
Also note that malloc()+memset() can choose byte values other than 0;
and for floating point then bytes such as 0xFF (which causes NaN)
might be preferable because it effectively re-enables some checking
for uninit.
Also note that there is a feature of glibc malloc() such that the shell
environment variable MALLOC_PERTURN_=NNN (note the trailing underscore)
will do this for *all* calls to malloc().

For cases when the uninit is in not all the bits of a variable,
then you can use valgrind 'monitor' commands in a gdbserver to print
the status of each bit.  See the manual section 3.2: Debugging your
program using Valgrind gdbserver and GDB.

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Nicholas N. <n.n...@gm...>]

Hi,

Re-run with the *--track-origins=yes *flag enabled and it will give you
more detail about where the uninitialized value comes from. (That option
isn't on by default because it makes Valgrind run more slowly.)

Nick

On Sun, 16 Jun 2024 at 06:13, Thomas Wollenzin <wol...@ms...> 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
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[David C. <dcc...@ac...>]

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 Cha...@ac...
     Chapman Consulting -- San Jose, CA
     EDA Software Developer, Expert Witness
     www.chapman-consulting-sj.com
     2018-2019 Chair, IEEE Consultants' Network of Silicon Valley

[Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'

[Thomas W. <wol...@ms...>]

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