valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] alternative ways of communication

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

On 04-07-24 14:26, Thomas Wollenzin wrote:
> Hi,
> 
> I was wondering whether there are other ways of communication for the 
> Valgrind community. In particular I'm thinking Slack or Discord?

The main problem that I see with these platforms is that the perceived 
ease of access means that there are a lot of low quality questions 
without any follow-up from the OP.

We use Slack at work. It's OK, but then it's not a public forum.

I recently tried using the ARM Discord server. There are many channels 
and the busy ones are flooded with noise. I don't find it to be a good 
way to communicate. There is a Discord server for the macOS Valgrind 
port, which is even quieter than IRC.

I also use Mattermost which is fairly good. It's used by WG21 for C++ 
standardization.

It seems like what I'm saying is the better ones have restricted access. 
That wouldn't be much use for Valgrind.

A+
Paul

Re: [Valgrind-users] alternative ways of communication

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

Hi Thomas,

On Thu, 2024-07-04 at 14:26 +0000, Thomas Wollenzin wrote:
> I was wondering whether there are other ways of communication for the Valgrind community.

We do have mailinglists. And there is an IRC channel for Valgrind
developers: #valgrind-dev at irc.libera.chat but users are also more
than welcome. See https://valgrind.org/support/mailing_lists.html

And of course bugzilla:
https://valgrind.org/support/bug_reports.html

> In particular I'm thinking Slack or Discord?

Slack and Discord are proprietary platforms.
Please don't use them for free software projects.
Good background, plus alternatives, is here:
https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS.html

Cheers,

Mark

[Valgrind-users] alternative ways of communication

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

Hi,

I was wondering whether there are other ways of communication for the Valgrind community. In particular I'm thinking Slack or Discord?

Cheers,
Thomas

Re: [Valgrind-users] helgrind question regarding 'Possible data race during write of size 8'

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

Thanks for the reply, Julian.
I indeed might have looked at an incomplete report.
After having worked with helgrind a few more days things make more sense now.

Cheers,
Thomas
________________________________
From: Julian Seward <jse...@gm...>
Sent: Friday, June 28, 2024 12:44 PM
To: Thomas Wollenzin <wol...@ms...>; val...@li... <val...@li...>
Subject: Re: [Valgrind-users] helgrind question regarding 'Possible data race during write of size 8'


At least in the text you included, there's nothing that indicates what
the the other thread/access is.  We have:

> Possible data race during write of size 8 at 0x58EEC60 by thread #1
> Locks held: none

and these, but they just tell you about the data address involved in
the race:

>   Address 0x58eec60 is 160 bytes inside a block of size 408 alloc'd
>     at 0x484BF58: operator new(unsigned long) (vg_replace_malloc.c:487)

>   Block was alloc'd by thread #1

There should be yet another stack which shows where the conflicting access
in the "other" thread is.

J

Re: [Valgrind-users] helgrind question regarding 'Possible data race during write of size 8'

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

At least in the text you included, there's nothing that indicates what
the the other thread/access is.  We have:

> Possible data race during write of size 8 at 0x58EEC60 by thread #1
> Locks held: none

and these, but they just tell you about the data address involved in
the race:

>   Address 0x58eec60 is 160 bytes inside a block of size 408 alloc'd
>     at 0x484BF58: operator new(unsigned long) (vg_replace_malloc.c:487)

>   Block was alloc'd by thread #1

There should be yet another stack which shows where the conflicting access
in the "other" thread is.

J

[Valgrind-users] helgrind question regarding 'Possible data race during write of size 8'

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

Hi,

I'm running helgrind against our code base and see this report. I once again cannot include all the code due to its proprietary and disclosed nature.

Possible data race during write of size 8 at 0x58EEC60 by thread #1
Locks held: none
   at 0x4A87603: ...
   by 0xE818EB4: ...
   by 0xE816B04: ...
   by 0xE816ABE: ...
   by 0xDD80701: ...
   by 0xDD80701: ...
   by 0xDD1FF8C: ...
   by 0x42503E: ...
   by 0x4263B0: ...
   by 0x4267E6: ...
 Address 0x58eec60 is 160 bytes inside a block of size 408 alloc'd
   at 0x484BF58: operator new(unsigned long) (vg_replace_malloc.c:487)
   by 0xE816395: ...
   by 0xE8143DC: ...
   by 0xE8143DC: ...
   by 0x4A64C49: ...
   by 0xDD7427A: ...
   by 0xDD7E472: ...
   by 0xDD7E58E: ...
   by 0xDD1FF8C: ...
   by 0x42503E: ...
   by 0x4263B0: ...
   by 0x4267E6: ...
 Block was alloc'd by thread #1
I'm a bit confused as to how this can be a data race if there's only the main thread involved. Could this be a false positive or how do I read this report correctly?

Thanks,
Thomas

Re: [Valgrind-users] [Valgrind-developers] A thousand bugs

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

On 23-06-24 15:43, Mark Wielaard wrote:
> Hi all,
> 
> On Thu, Nov 16, 2023 at 08:22:33PM +0100, Mark Wielaard wrote:
>> Valgrind is more than 20 years old and we have been collecting
>> bugs slightly faster than we have been able to close them. Which means
>> we now have around a thousand bugs open. This is a slightly
>> intimidating number.
> 
> I am happy to say that we have been closing bugs faster than they are
> being filed in the last 6 months. There have been 85 new bugs filed
> and 110 bugs closed. There are now "only" 975 bugs open.

So we should clear the backlog in about 20 years time.

A+
Paul

Re: [Valgrind-users] [Valgrind-developers] A thousand bugs

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

Hi all,

On Thu, Nov 16, 2023 at 08:22:33PM +0100, Mark Wielaard wrote:
> Valgrind is more than 20 years old and we have been collecting
> bugs slightly faster than we have been able to close them. Which means
> we now have around a thousand bugs open. This is a slightly
> intimidating number.

I am happy to say that we have been closing bugs faster than they are
being filed in the last 6 months. There have been 85 new bugs filed
and 110 bugs closed. There are now "only" 975 bugs open.

Great progress, but still slightly intimidating. So if people could
take a look and confirm or close issues that would be appreciated.

> But some of the bugs are more than 10 years old (the oldest bugs are
> from 2004). So some of them are likely not really relevant anymore.
> 
> If people could do some quick spot checks of some of these bugs that
> would be really appreciated.
> 
> The bugs can be found here:
> https://bugs.kde.org/buglist.cgi?product=valgrind&resolution=---
> Or per component here:
> https://bugs.kde.org/describecomponents.cgi?product=valgrind
> 
> If you filed a bug yourself please look if the issue is still
> relevant. Please add a comment saying so if it is, or close it if it
> isn't. Same if it has a simple reproducer. If it has a patch attached
> please check if it still applies.
> 
> Please don't go out of your way to close bugs, even old bugs can still
> be relevant. But it would be good to know if they really still are and
> we need to take another look at them.
> 
> Thanks,
> 
> Mark

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

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

That's indeed very interesting Paul. Thanks for making me aware.

Thomas

________________________________
From: Paul Floyd via Valgrind-users <val...@li...>
Sent: Wednesday, June 19, 2024 10:07 PM
To: val...@li... <val...@li...>
Subject: Re: [Valgrind-users] Question regarding 'Conditional jump or move depends on uninitialised value(s)'



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


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

> It seems optimizatin of the code will make
> it indistinquisable from explicit initialization.

So what you want is  -ftrivial-auto-var-init=$POISON
where POISON is something like 0xA5 or 'deaddead'
and memcheck is told the value used for POISON.
The programmer should specify a value that
is highly unlikely to be a legitimate value.

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