valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

On Sat, 2024-07-20 at 11:01 +0200, Philippe Waroquiers via Valgrind-
users wrote:
> On Wed, 2024-07-17 at 20:47 +0200, Julian Seward wrote:
> > Also, there is no gdbserver involved unless you start it with
> > specific
> > flags to invoke GDB support.  But that is not the default.
> 
> Note that the option to activate or not the gdbserver in valgrind is:
>     --vgdb=no|yes|full        activate gdbserver? [yes]
> Default option is yes, which means that the gdbserver is activated
> but has
> no impact on the generated code. With full, the generated code is
> slower but allows
> more precise breakpoints and watchpoints.
I am running with the default 'yes' - so I can query it with shell
vgdb.

> 
> Unless you also use e.g. --vgdb-stop-at= or --vgdb-error=XXXX, 
> -vgdb=yes should have no visible impact and cause no interaction
> between
> different valgrind processes.
> 
I agree there is no interaction in how I am using valgrind (see last
post), but not knowing this before prompted me to ask the question on
this list. I did not use --vgd-stop-at or setup --multi mode of
interacting with gdbserver via gdb. Nevertheless, 'target remote |
vgdb' is equivalent to attaching to the process in gdb, allowing full
debugging, though without the vgdb commands (v.clo, v.info etc). These
queries elicit no response presumably because valgrind-monitor.py is
missing from gdb.

> Note that if --vgdb=no is specified, a set of features (such as
> external control
> from the shell, callgrind_control, ...) will not be available (in
> addition to no 
> no debugging).
Once I attached to the valgrind process from gdb, any further query
from shell vgdb elicits a response I'm busy talking to another client
already, can't talk to you. Detaching in gdb then allows further
queries with shell vgdb. This leads me to another question:

If you vgdb v.kill the valgrind process, can you and how, get a final
detail report of all the errors which is generated when the process
terminates "normally"?

Thanks,
Elaine

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

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Philippe W. <phi...@sk...>]

On Wed, 2024-07-17 at 20:47 +0200, Julian Seward wrote:
> Also, there is no gdbserver involved unless you start it with specific
> flags to invoke GDB support.  But that is not the default.

Note that the option to activate or not the gdbserver in valgrind is:
    --vgdb=no|yes|full        activate gdbserver? [yes]
Default option is yes, which means that the gdbserver is activated but has
no impact on the generated code. With full, the generated code is slower but allows
more precise breakpoints and watchpoints.

Unless you also use e.g. --vgdb-stop-at= or --vgdb-error=XXXX, 
-vgdb=yes should have no visible impact and cause no interaction between
different valgrind processes.

Note that if --vgdb=no is specified, a set of features (such as external control
from the shell, callgrind_control, ...) will not be available (in addition to no 
no debugging).

Thanks
Philippe

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

On Thu, 2024-07-18 at 07:17 +0200, Julian Seward wrote:
> On 18/07/2024 00:00, Tsiang Elaine Reisler wrote:
> > Yes, there is cross-thread synchronization via shared memory, but
> > not
> > cross-process. I am just running helgrind and drd on exactly the
> > same
> > stand-alone program.
> 
> What CPU are you running this on?
> 
> J
Epyc 7513.

I have done some more experiments. It seems the problem is not in
valgrind. Ordinarily I don't pay much attention to NUMA, just run with
whatever defaults. I can succeed in binding the separate valgrinds to
different nodes, but only by chance, if I start them from various
virtual terminals (same with system consoles). As far as what I want to
do at this point, that is a satisfactory solution.

However, trying to bind valgrind explicitly by numactl --cpunodebind
does not work. It starts and runs valgrind through the first segment.
Everyone sounds happy. But afterwards, that process never gets another
robin round. I have no idea - no search results.

Thanks,
Elaine

PS - apologies for the previous redundant post. I got a rejection
notice by sourceforge because I used a different reply-to address than
my send address. Without checking the list, I made another post.

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

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

On 18/07/2024 00:00, Tsiang Elaine Reisler wrote:
> Yes, there is cross-thread synchronization via shared memory, but not
> cross-process. I am just running helgrind and drd on exactly the same
> stand-alone program.

What CPU are you running this on?

J

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

On Wed, 2024-07-17 at 20:47 +0200, Julian Seward wrote:
> 
> I don't follow the details exactly, but FWIW .. valgrind running an
> application is "just another normal process".  It has no
> understanding
> of or special-casing relating to NUMA, or particular cores/nodes in a
> multiprocessor machine.
That was my understanding also, that each valgrind instance is stand-
alone - hence two should run on separate nodes the same as on the same
node, but with better access to memory/cpu because they do not have to
contend for them on the same node
> 
> > My conjecture is that the valgrind core is one instance of the
> > gdbserver, which then spawns the tools, and hence one should not
> > force
> 
> Also, there is no gdbserver involved unless you start it with
> specific
> flags to invoke GDB support.  But that is not the default.
> 
> It might be that if you are doing cross-process synchronisation via
> accesses to shared memory, that depend on specific details of the
> machine's
> memory coherence model, that you could wind up with problems. 
> Something
> like that I could believe.
> 
> J
> 
> 
Yes, there is cross-thread synchronization via shared memory, but not
cross-process. I am just running helgrind and drd on exactly the same
stand-alone program.

Thanks,
Elaine
> 

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

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

On Wed, 2024-07-17 at 20:47 +0200, Julian Seward wrote:
> 
> I don't follow the details exactly, but FWIW .. valgrind running an
> application is "just another normal process".  It has no
> understanding
> of or special-casing relating to NUMA, or particular cores/nodes in a
> multiprocessor machine.
That was my understanding also, that each valgrind instance is stand-
alone - hence two should run on separate nodes the same as on the same
node, but with better access to memory/cpu because they do not have to
contend for them on the same node.
> 
> > My conjecture is that the valgrind core is one instance of the
> > gdbserver, which then spawns the tools, and hence one should not
> > force
> 
> Also, there is no gdbserver involved unless you start it with
> specific
> flags to invoke GDB support.  But that is not the default.
> 
> It might be that if you are doing cross-process synchronisation via
> accesses to shared memory, that depend on specific details of the
> machine's
> memory coherence model, that you could wind up with problems. 
> Something
> like that I could believe.
> 
> J
Yes, there is cross-thread synchronization via shared memory, but not
cross-process. I am just running helgrind and drd on exactly the same
stand-alone program.

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

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

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

I don't follow the details exactly, but FWIW .. valgrind running an
application is "just another normal process".  It has no understanding
of or special-casing relating to NUMA, or particular cores/nodes in a
multiprocessor machine.

> My conjecture is that the valgrind core is one instance of the
> gdbserver, which then spawns the tools, and hence one should not force

Also, there is no gdbserver involved unless you start it with specific
flags to invoke GDB support.  But that is not the default.

It might be that if you are doing cross-process synchronisation via
accesses to shared memory, that depend on specific details of the machine's
memory coherence model, that you could wind up with problems.  Something
like that I could believe.

J

[Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

Hi,

It appears that when the default policy is preferred local, the two
instances (one helgrind, one drd) are run on the same node.

I thought I could afford more processor/memory access by forcing the
two instances to run on separate nodes. When I succeeded in doing that,
one process starts up fine, but is apparently not being run, while the
other process proceeds normally. BTW, I am running from /dev/pts in
gnome.

My conjecture is that the valgrind core is one instance of the
gdbserver, which then spawns the tools, and hence one should not force
the tools to run on separate nodes. However, once that is done, it
becomes difficult to correct without restarting the process that is
already running, or maybe even rebooting - too much sunk cost.

So I thought to ask this question while I am waiting.

Thanks,
Elaine

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