valgrind-users — General discussion list for Valgrind users

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

Re: [Valgrind-users] Semaphore error on Helgrind and Drd?

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

On 25/05/2024 12:29, Paulo Ferreira wrote:
> Error message from Helgrind: 
> 
> $ valgrind --tool=helgrind  ./prog 
> ...
> ==6587== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
> ==6587==    at 0x4850069: sem_wait_WRK (hg_intercepts.c:3155)
> ==6587==    by 0x4851180: sem_wait@* (hg_intercepts.c:3174)
> ==6587==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
> …
> 
> Error message from Drd: 
> 
> $ valgrind --tool=drd --trace-semaphore=yes  ./prog
> ...
> ==6828== [1] sem_wait      0x487f000 value 0 -> 4294967295
> ==6828== Invalid semaphore: semaphore 0x487f000
> ==6828==    at 0x4866C1A: sem_wait_intercept (drd_pthread_intercepts.c:1570)
> ==6828==    by 0x4866C1A: sem_wait@* (drd_pthread_intercepts.c:1578)
> ==6828==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
> ==6828== semaphore 0x487f000 was first observed at:
> ==6828==    at 0x4865A16: sem_open_intercept (drd_pthread_intercepts.c:1527)
> ==6828==    by 0x4865A16: sem_open@* (drd_pthread_intercepts.c:1538)
> ==6828==    by 0x1091D3: main (in /media/sf_antiX/erros/duvida/prog)
> …  
> 
> So the issue seems to be that according to Drd a semaphore that has the value of zero, with a sem_wait() gets decremented to 4294967295. (????????) 
> I have the sample code on the end of this message, and I have tried to run the code on several recent versions of Valgrind (32.3 and others), and on x86-64 using antiX Linux, MX Linux, Ubuntu Linux and FreeBSD. I have also tried ARM 64 bits under Ubuntu, and the behaviour is the same. The sample program seems to work ok. 
> 
> 	pid_t pid = fork(); 
>     if (pid>0) // Parent process
Hi

Semaphores can be used with both threads and processes. I don't think that Valgrind works with semaphores across processes, only threads. 

Regards

Paul

[Valgrind-users] Simple list of functions ever called

[Byron H. <by...@in...>]

For the purposes of studying dead-code elimination in LLVM, I'd like to
generate a simple list of all the functions that are ever called by the
target program. There's no need for any timing or frequency reports or
backtraces or any other details. So far, the best solution I can find
is to filter callgrind output like this:

    grep -E "^c?fn" callgrind/output.raw | cut -d " " -f 2- | grep -Ev
"^0x|^c?fn"

It doesn't seem highly reliable, since I'm just picking out entries by
sort of guessing, then checking the results with gdb (setting a
breakpoint on every symbol not encountered by callgrind). All target
programs are trivial unit tests with rigid, deterministic behavior, but
it would still be nicer to have a more formally defined approach for
extracting a precise set of function symbols for which invocation was
observed during the execution. Thanks in advance for any suggestions.

Byron

Re: [Valgrind-users] Semaphore error on Helgrind and Drd?

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

On 25/05/2024 12:29, Paulo Ferreira wrote:
> Error message from Helgrind: 
> 
> $ valgrind --tool=helgrind  ./prog 
> ...
> ==6587== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
> ==6587==    at 0x4850069: sem_wait_WRK (hg_intercepts.c:3155)
> ==6587==    by 0x4851180: sem_wait@* (hg_intercepts.c:3174)
> ==6587==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
> …
> 
> Error message from Drd: 
> 
> $ valgrind --tool=drd --trace-semaphore=yes  ./prog
> ...
> ==6828== [1] sem_wait      0x487f000 value 0 -> 4294967295
> ==6828== Invalid semaphore: semaphore 0x487f000
> ==6828==    at 0x4866C1A: sem_wait_intercept (drd_pthread_intercepts.c:1570)
> ==6828==    by 0x4866C1A: sem_wait@* (drd_pthread_intercepts.c:1578)
> ==6828==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
> ==6828== semaphore 0x487f000 was first observed at:
> ==6828==    at 0x4865A16: sem_open_intercept (drd_pthread_intercepts.c:1527)
> ==6828==    by 0x4865A16: sem_open@* (drd_pthread_intercepts.c:1538)
> ==6828==    by 0x1091D3: main (in /media/sf_antiX/erros/duvida/prog)
> …  
> 
> So the issue seems to be that according to Drd a semaphore that has the value of zero, with a sem_wait() gets decremented to 4294967295. (????????) 
> I have the sample code on the end of this message, and I have tried to run the code on several recent versions of Valgrind (32.3 and others), and on x86-64 using antiX Linux, MX Linux, Ubuntu Linux and FreeBSD. I have also tried ARM 64 bits under Ubuntu, and the behaviour is the same. The sample program seems to work ok. 
> 
> 	pid_t pid = fork(); 
>     if (pid>0) // Parent process
Hi

Semaphores can be used with both threads and processes. I don't think that Valgrind works with semaphores across processes, only threads. 

Regards

Paul

[Valgrind-users] Semaphore error on Helgrind and Drd?

[Paulo F. <pa...@ke...>]

Error message from Helgrind: 

$ valgrind --tool=helgrind  ./prog 
...
==6587== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
==6587==    at 0x4850069: sem_wait_WRK (hg_intercepts.c:3155)
==6587==    by 0x4851180: sem_wait@* (hg_intercepts.c:3174)
==6587==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
…

Error message from Drd: 

$ valgrind --tool=drd --trace-semaphore=yes  ./prog
...
==6828== [1] sem_wait      0x487f000 value 0 -> 4294967295
==6828== Invalid semaphore: semaphore 0x487f000
==6828==    at 0x4866C1A: sem_wait_intercept (drd_pthread_intercepts.c:1570)
==6828==    by 0x4866C1A: sem_wait@* (drd_pthread_intercepts.c:1578)
==6828==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
==6828== semaphore 0x487f000 was first observed at:
==6828==    at 0x4865A16: sem_open_intercept (drd_pthread_intercepts.c:1527)
==6828==    by 0x4865A16: sem_open@* (drd_pthread_intercepts.c:1538)
==6828==    by 0x1091D3: main (in /media/sf_antiX/erros/duvida/prog)
…  

So the issue seems to be that according to Drd a semaphore that has the value of zero, with a sem_wait() gets decremented to 4294967295. (????????) 
I have the sample code on the end of this message, and I have tried to run the code on several recent versions of Valgrind (32.3 and others), and on x86-64 using antiX Linux, MX Linux, Ubuntu Linux and FreeBSD. I have also tried ARM 64 bits under Ubuntu, and the behaviour is the same. The sample program seems to work ok. 

My thanks to all the Valgrind developers for the wonderful software they created, and I sincerely hope the issue is on my side (between chair and keyboard).

Paulo Ferreira 
======================
#include <stdio.h>
#include <fcntl.h>
#include <semaphore.h>
#include <unistd.h>
#include <sys/wait.h>

#define NUM 10 

int main(void)
{
    int i;
    sem_t *sem1; // First semaphore
    sem_t *sem2; // Second semaphore

    // create, initialize semaphores
    sem1 = sem_open("/semaphore1", O_CREAT,  0600, 0);
    sem2 = sem_open("/semaphore2", O_CREAT,  0600, 1);
	pid_t pid = fork(); 
    if (pid>0) // Parent process
    {
        for (i = 0; i < NUM;  i++)
        {
            sem_wait(sem2); // Lock the semaphore
            write(1, "a\n", 2);
            sem_post(sem1); // Release the semaphore lock
        }
        wait(NULL);
    }
    else // Child process
    {
        for (i = 0; i < NUM; i++)
        {   
		    sem_wait(sem1); // Lock the semaphore
            write(1, "b\n", 2);
            sem_post(sem2); // Release the semaphore lock
        }
    }


	// Close the Semaphores
    sem_close(sem1);
    sem_unlink("/semaphore1");
    sem_close(sem2);
    sem_unlink("/semaphore2");
    return 0;
}
==========================

 

    

Re: [Valgrind-users] Valgrind-3.23.0.RC2 is available for testing

[Simon S. <sim...@gn...>]

That's

clang version 18.1.4
Target: aarch64-unknown-linux-android24

No flags set at all (other than --enable-lto). Checking for warning flags noted in config.log:

CFLAGS_MPI='-g -O -fno-omit-frame-pointer -Wall -fpic'
FLAG_W_CAST_ALIGN='-Wcast-align'
FLAG_W_CAST_QUAL='-Wcast-qual'
FLAG_W_EMPTY_BODY='-Wempty-body'
FLAG_W_ENUM_CONVERSION='-Wenum-conversion'
FLAG_W_EXTRA='-Wextra'
FLAG_W_FORMAT='-Wformat'
FLAG_W_FORMAT_SECURITY='-Wformat-security'
FLAG_W_IGNORED_QUALIFIERS='-Wignored-qualifiers'
FLAG_W_NO_ATTRIBUTES='-Wno-attributes'
FLAG_W_NO_BUILTIN_MEMCPY_CHK_SIZE='-Wno-builtin-memcpy-chk-size'
FLAG_W_NO_EXPANSION_TO_DEFINED='-Wno-expansion-to-defined'
FLAG_W_NO_FORMAT_OVERFLOW='-Wno-format-overflow'
FLAG_W_NO_FORTIFY_SOURCE='-Wno-fortify-source'
FLAG_W_NO_FREE_NONHEAP_OBJECT='-Wno-free-nonheap-object'
FLAG_W_NO_INCOMPATIBLE_POINTER_TYPES_DISCARDS_QUALIFIERS='-Wno-incompatible-pointer-types-discards-qualifiers'
FLAG_W_NO_INFINITE_RECURSION='-Wno-infinite-recursion'
FLAG_W_NO_MEMSET_TRANSPOSED_ARGS='-Wno-memset-transposed-args'
FLAG_W_NO_MISMATCHED_NEW_DELETE='-Wno-mismatched-new-delete'
FLAG_W_NO_NONNULL='-Wno-nonnull'
FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT='-Wno-non-power-of-two-alignment'
FLAG_W_NO_OVERFLOW='-Wno-overflow'
FLAG_W_NO_POINTER_SIGN='-Wno-pointer-sign'
FLAG_W_NO_SIGN_COMPARE='-Wno-sign-compare'
FLAG_W_NO_STATIC_LOCAL_IN_INLINE='-Wno-static-local-in-inline'
FLAG_W_NO_SUSPICIOUS_BZERO='-Wno-suspicious-bzero'
FLAG_W_NO_UNINITIALIZED='-Wno-uninitialized'
FLAG_W_NO_UNUSED_BUT_SET_VARIABLE='-Wno-unused-but-set-variable'
FLAG_W_NO_UNUSED_FUNCTION='-Wno-unused-function'
FLAG_W_NO_UNUSED_VARIABLE='-Wno-unused-variable'
FLAG_W_WRITE_STRINGS='-Wwrite-strings'

Simon

Am 27. April 2024 14:05:59 MESZ schrieb Paul Floyd via Valgrind-users <val...@li...>:
>
>
>On 25-04-24 19:09, Simon Sobisch wrote:
>> 
>> 
>> Am 25.04.2024 um 20:55 schrieb Paul Floyd via Valgrind-users:
>>> 
>>> On 25-04-24 14:39, Simon Sobisch wrote:
>>> 
>>>> 3. compile warnings with clang on arm64 (in multiple files/positions with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, CALL_FN_W_WWW and CALL_FN_W_WWWW):
>>> 
>>> For the arm64 warnings, what OS were you usung?
>> 
>> That was Android running within Termux.
>
>Which version of clang is that using? And does it use any extra compiler flags?
>
>FreeBSD 14 with clang 16 (and 18) only produces a couple of warnings:
>
>
>integer.c:30:21: warning: unused function 'randUChar' [-Wunused-function]
>
>and
>
>arm64_features.c:28:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
>
>(well, they did, I just fixed them).
>
>I also tried adding -Winline-asm, still no warnings.
>
>A+
>Paul
>
>
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Valgrind-3.23.0.RC2 is available for testing

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

On 25-04-24 19:09, Simon Sobisch wrote:
> 
> 
> Am 25.04.2024 um 20:55 schrieb Paul Floyd via Valgrind-users:
>>
>> On 25-04-24 14:39, Simon Sobisch wrote:
>>
>>> 3. compile warnings with clang on arm64 (in multiple files/positions 
>>> with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, 
>>> CALL_FN_W_WWW and CALL_FN_W_WWWW):
>>
>> For the arm64 warnings, what OS were you usung?
> 
> That was Android running within Termux.

Which version of clang is that using? And does it use any extra compiler 
flags?

FreeBSD 14 with clang 16 (and 18) only produces a couple of warnings:


integer.c:30:21: warning: unused function 'randUChar' [-Wunused-function]

and

arm64_features.c:28:1: warning: non-void function does not return a 
value in all control paths [-Wreturn-type]

(well, they did, I just fixed them).

I also tried adding -Winline-asm, still no warnings.

A+
Paul

[Valgrind-users] Valgrind-3.23.0 is available

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

We are pleased to announce a new release of Valgrind, version 3.23.0,
available from https://valgrind.org/downloads/current.html.

See the release notes below for details of changes.

Our thanks to all those who contribute to Valgrind's development.  This
release represents a great deal of time, energy and effort on the part
of many people.

Happy and productive debugging and profiling,

-- The Valgrind Developers

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD, AMD64/FreeBSD
and ARM64/FreeBSD  There is also preliminary support for X86/macOS 10.13,
AMD64/macOS 10.13 and nanoMIPS/Linux.

* ==================== CORE CHANGES ===================

* --track-fds=yes will now also warn about double closing of file
  descriptors. Printing the context where the file descriptor was
  originally opened and where it was previously closed.

* --track-fds=yes also produces "real" errors now which can be
  suppressed and work with --error-exitcode. When combined with
  --xml the xml-output now also includes FdBadClose and FdNotClosed
  error kinds (see docs/internals/xml-output-protocol5.txt).

* The option --show-error-list=no|yes now accepts a new value all.
  This indicates to also print the suppressed errors.
  This is useful to analyse which errors are suppressed by which
  suppression entries.
  The valgrind monitor command 'v.info all_errors' similarly now
  accepts a new optional argument 'also_suppressed' to show
  all errors including the suppressed errors.

* ================== PLATFORM CHANGES =================

* Added ARM64 support for FreeBSD.

* ARM64 now supports dotprod instructions (sdot/udot).

* AMD64 better supports code build with -march=x86-64-v3.
  fused-multiple-add instructions (fma) are now emulated more
  accurately. And memcheck now handles __builtin_strcmp using 128/256
  bit vectors with sse4.1, avx/avx2.

* S390X added support for NNPA (neural network processing assist)
  facility vector instructions VCNF, VCLFNH, VCFN, VCLFNL, VCRNF and
  NNPA (z16/arch14).

* X86 recognizes new binutils-2.42 nop patterns.

* ==================== TOOL CHANGES ===================

* The none tool now also supports xml output.

* ==================== FIXED BUGS ====================

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.


283429  ARM leak checking needs CLEAR_CALLER_SAVED_REGS
281059  Cannot connect to Oracle using valgrind
328563  make track-fds support xml output
362680  --error-exitcode not honored when file descriptor leaks are found
369723  __builtin_longjmp not supported in clang/llvm on Android arm64 target
390269  unhandled amd64-darwin syscall: unix:464 (openat_nocancel)
401284  False positive "Source and destination overlap in strncat"
428364  Signals inside io_uring_enter not handled
437790  valgrind reports "Conditional jump or move depends on uninitialised
        value" in memchr of macOS 10.12-10.15
460616  disInstr(arm64): unhandled instruction 0x4E819402 (dotprod/ASIMDDP)
463458  memcheck/tests/vcpu_fnfns fails when glibc is built for x86-64-v3
463463  none/tests/amd64/fma fails when executed on a x86-64-v3 system
466762  Add redirs for C23 free_sized() and free_aligned_sized()
466884  Missing writev uninit padding suppression for _XSend
471036  disInstr_AMD64: disInstr miscalculated next %rip on RORX imm8, m32/64, r32/6
471222  support tracking of file descriptors being double closed
474160  If errors-for-leak-kinds is specified, exit-on-first-error should only exit
        on one of the listed errors.
475498  Add reallocarray wrapper
476025  Vbit expected test results for Iop_CmpGT64Ux2 are wrong
476320  Build failure with GCC
476331  clean up generated/distributed filter scripts
476535  Difference in allocation size for massif/tests/overloaded-new between
        clang++/libc++ and g++/libstdc++
476548  valgrind 3.22.0 fails on assertion when loading debuginfo file
        produced by mold
476708  valgrind-monitor.py regular expressions should use raw strings
476780  Extend strlcat and strlcpy wrappers to GNU libc
476787  Build of Valgrind 3.21.0 fails when SOLARIS_PT_SUNDWTRACE_THRP is
        defined
476887  WARNING: unhandled amd64-freebsd syscall: 578
477198  Add fchmodat2 syscall on linux
477628  Add mremap support for Solaris
477630  Include ucontext.h rather than sys/ucontext.h in Solaris sources
477719  vgdb incorrectly replies to qRcmd packet
478211  Redundant code for vgdb.c and Valgrind core tools
478624  Valgrind incompatibility with binutils-2.42 on x86 with new nop patterns
        (unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26
478837  valgrind fails to read debug info for rust binaries
479041  Executables without RW sections do not trigger debuginfo reading
480052  WARNING: unhandled amd64-freebsd syscall: 580
480126  Build failure on Raspberry Pi 5 / OS 6.1.0-rpi7-rpi-v8
480405  valgrind 3.22.0 "m_debuginfo/image.c:586 (set_CEnt):
        Assertion '!sr_isError(sr)' failed."
480488  Add support for FreeBSD 13.3
480706  Unhandled syscall 325 (mlock2)
481127  amd64: Implement VFMADD213 for Iop_MAddF32
481131  [PATCH] x86 regtest: fix clobber lists in generated asm statements
481676  Build failure on Raspberry Pi 5 Ubuntu 23.10 with clang
481874  Add arm64 support for FreeBSD
483786  Incorrect parameter indexing in FreeBSD clock_nanosleep syscall wrapper
484002  Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
484426  aarch64: 0.5 gets rounded to 0
484480  False positives when using sem_trywait
484935  [patch] Valgrind reports false "Conditional jump or move depends on
        uninitialised value" errors for aarch64 signal handlers
485148  vfmadd213ss instruction is instrumented incorrectly (the remaining
        part of the register is cleared instead of kept unmodified)
485487  glibc built with -march=x86-64-v3 does not work due to ld.so strcmp
485778  Crash with --track-fds=all and --gen-suppressions=all
n-i-bz  Add redirect for memccpy

To see details of a given bug, visit
  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed above.

(3.23.0.RC1: 19 Apr 2024)
(3.23.0.RC2: 24 Apr 2024)