valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Docker Support

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

On 04-03-24 11:42, jinesh gada wrote:
> Hi Everyone,
> 
> I am working on integrating a docker based application on a virtual 
> machine with Valgrind.
> 
> I have bind the Valgrind libraries and required folder structure with 
> the container.
> 
> But on running my app with Valgrind I'm facing an issue saying SIGILL 
> error in ld-2.3.so <http://ld-2.3.so>
> 
> Can you suggest how shall I proceed.

My basic advice is to not use Docker. I've never used it, but I have 
tried FreeBSD jails. The experience was unsatisfactory. The main problem 
is that these systems only provide lightweight virtualization. That 
means that Valgrind will detect an incorrect or incomplete environment 
and will likely not work correctly.

Full virtualization (VMware, VirtualBox) will work better. The 
virtualization will still not be the same as running directly on the 
underlying operating system but in my experience it is good enough.

A+
Paul

[Valgrind-users] Docker Support

[jinesh g. <301...@gm...>]

Hi Everyone,

I am working on integrating a docker based application on a virtual machine
with Valgrind.

I have bind the Valgrind libraries and required folder structure with the
container.

But on running my app with Valgrind I'm facing an issue saying SIGILL error
in ld-2.3.so

Can you suggest how shall I proceed.

[Valgrind-users] massif a process which uses pcap and linux capabilities.

[Nicolas S. <nic...@ya...>]

Hi everyone,
I came up with an issue using valgrind and I would like to know if there is a solution. I read the documentation but found nothing related to the topic.So here what I try to do :I use memcheck on a process that sniffs the network using pcap. Of course it has "cap_net_raw=eip" capabilities. I can use valgrind (memcheck) in this situation if :--> I remove the capabilities of my sniffer process.--> I set the same capabilities to valgrind binary (with setcap)
Now I would like to use massif. I have the same setup I used for memcheck. Valgrind is executed but the process itself within valgrind prints out it is not able to sniff the network using pcap.
If someone tried to valgrind a process which uses pcap through privileges (memcheck/massif) I would be interested to get some hints on that aspect.
Have a nice week-end,
Nicolas.

Re: [Valgrind-users] Missing the library file /lib/valgrind/libmpiwrap-<platform>.so

[Rambaks, A. <and...@rw...>]

Hi Simon,


thank you for your reply!


I didn't suspect a problem with the configuration script and I am relatively new to Linux, i.e. I am not that proficient in reading the terminal outputs yet. I will try a new installation later in the day and get back to you.


However I have a different question regarding the installation of Valgrind with OpenMPI. The configuration file of OpenMPI has a FLAG --with-valgrind (I think it got introduced with MPI 5.x.x, not quite sure), which only works if Valgrind is already installed. However, Valgrind cannot be configured with the flag --with-mpicc, if OpenMPI is not installed (interdependency?). Does this mean that I first have to install Valgrind, then install OpenMPI (--with-valgrind enabled) and then install Valgrind again with the flag --with-mpicc ?


With kind regards

Andris Rambaks

________________________________
Von: Simon Sobisch <sim...@gn...>
Gesendet: Donnerstag, 8. Februar 2024 19:49:27
An: Rambaks, Andris
Cc: val...@li...
Betreff: Re: [Valgrind-users] Missing the library file /lib/valgrind/libmpiwrap-<platform>.so

Am 08.02.2024 um 18:25 schrieb Rambaks, Andris:
> Dear community,
>
> I am trying to install Valgrind for use with Open MPI. However, my
> installation is missing the library file
> */lib/valgrind/**libmpiwrap-<platform>.so*. I did configure
> release 3.22.0 with the /--with-mpicc/ flag and successefully ran make
> and make install.
>
> I am running Ubuntu 22.04.3 LTS with Open MPI 5.0.2. I can't seem to
> find the problem; the config.log returns:
>
> configure:18197: checking for mpicc
> configure:18221: found /usr/local/bin/mpicc
> configure:18234: result: /usr/local/bin/mpicc
> configure:18319: checking primary target for usable MPI2-compliant C
> compiler and mpi.h
> configure:18347: yes -o conftest -g -O -fno-omit-frame-pointer -Wall
> -fpic -m64  -fpic -shared -m64 conftest.c  >&5
> yes: invalid option -- 'o'
> Try 'yes --help' for more information.
> configure:18347: $? = 1
> configure: failed program was:
> | /* confdefs.h */
>
> I would really appreciate the help.
>
> Kind regards
>
> Andris Rambaks

Hi Andris,

the problem is that configure was told that the name of the
MPI2-compliant C compiler is "yes".
As you didn't explicit specify this (at least not intended to), this is
(also) a problem of the configure script.

It does hint what happens in your case to the user, as configure --help
says
   --with-mpicc=           Specify name of MPI2-ised C compiler


You did specify --with-mpicc - per default that is identical to
--with-mpicc=yes (--without-mpicc would be resolved ti --with-mpicc=no),
and that's not checked in the configure script and used "as is".


So to work around that that:

a) either drop the option completely (configure should then find it on
    its own if it is named mpicc and somwehere in
        $PATH:/usr/lib/openmpi/bin:/usr/lib64/openmpi/bin
b) specify it explicit using its full path passed to --with-mpicc (sadly
    I couldn't find how that is called/to be installed in your
    environment).


To fix this, the configure script should:
* explicit check for both "yes" and "no" and raise a clear error
* possibly add more compiler names / paths to its list

How is the "MPI2-compliant C compiler" named on your system, and where
is it installed to?

Kind regards,
Simon

Re: [Valgrind-users] Missing the library file /lib/valgrind/libmpiwrap-<platform>.so

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

Am 08.02.2024 um 18:25 schrieb Rambaks, Andris:
> Dear community,
> 
> I am trying to install Valgrind for use with Open MPI. However, my 
> installation is missing the library file 
> */lib/valgrind/**libmpiwrap-<platform>.so*. I did configure 
> release 3.22.0 with the /--with-mpicc/ flag and successefully ran make 
> and make install.
> 
> I am running Ubuntu 22.04.3 LTS with Open MPI 5.0.2. I can't seem to 
> find the problem; the config.log returns:
> 
> configure:18197: checking for mpicc
> configure:18221: found /usr/local/bin/mpicc
> configure:18234: result: /usr/local/bin/mpicc
> configure:18319: checking primary target for usable MPI2-compliant C 
> compiler and mpi.h
> configure:18347: yes -o conftest -g -O -fno-omit-frame-pointer -Wall 
> -fpic -m64  -fpic -shared -m64 conftest.c  >&5
> yes: invalid option -- 'o'
> Try 'yes --help' for more information.
> configure:18347: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> 
> I would really appreciate the help.
> 
> Kind regards
> 
> Andris Rambaks

Hi Andris,

the problem is that configure was told that the name of the 
MPI2-compliant C compiler is "yes".
As you didn't explicit specify this (at least not intended to), this is 
(also) a problem of the configure script.

It does hint what happens in your case to the user, as configure --help 
says
   --with-mpicc=           Specify name of MPI2-ised C compiler


You did specify --with-mpicc - per default that is identical to 
--with-mpicc=yes (--without-mpicc would be resolved ti --with-mpicc=no), 
and that's not checked in the configure script and used "as is".


So to work around that that:

a) either drop the option completely (configure should then find it on
    its own if it is named mpicc and somwehere in
        $PATH:/usr/lib/openmpi/bin:/usr/lib64/openmpi/bin
b) specify it explicit using its full path passed to --with-mpicc (sadly
    I couldn't find how that is called/to be installed in your
    environment).


To fix this, the configure script should:
* explicit check for both "yes" and "no" and raise a clear error
* possibly add more compiler names / paths to its list

How is the "MPI2-compliant C compiler" named on your system, and where 
is it installed to?

Kind regards,
Simon

[Valgrind-users] Missing the library file /lib/valgrind/libmpiwrap-<platform>.so

[Rambaks, A. <and...@rw...>]

Dear community,


I am trying to install Valgrind for use with Open MPI. However, my installation is missing the library file /lib/valgrind/libmpiwrap-<platform>.so. I did configure release 3.22.0 with the --with-mpicc flag and successefully ran make and make install.


I am running Ubuntu 22.04.3 LTS with Open MPI 5.0.2. I can't seem to find the problem; the config.log returns:


configure:18197: checking for mpicc
configure:18221: found /usr/local/bin/mpicc
configure:18234: result: /usr/local/bin/mpicc
configure:18319: checking primary target for usable MPI2-compliant C compiler and mpi.h
configure:18347: yes -o conftest -g -O -fno-omit-frame-pointer -Wall -fpic -m64  -fpic -shared -m64 conftest.c  >&5
yes: invalid option -- 'o'
Try 'yes --help' for more information.
configure:18347: $? = 1
configure: failed program was:
| /* confdefs.h */


I would really appreciate the help.


Kind regards


Andris Rambaks

[Valgrind-users] FOSDEM 2024, Debuggers and Analysis tools devroom

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

Hi valgrind hackers and users,

Fosdem is Saturday and Sunday, 3 & 4 February, in Brussels. It is a
great conference to hear about various technical topics and to meet
others. In the Debuggers and Analysis tools devroom there will also be
a talk from Bruno Lathuilière about Verrou : a valgrind tool dedicated
to floating point error diagnosis

https://fosdem.org/2024/
https://fosdem.org/2024/schedule/track/debuggers-and-analysis/
https://fosdem.org/2024/schedule/event/fosdem-2024-2020-verrou-a-valgrind-tool-dedicated-to-floating-point-error-diagnosis/

Hope to see you there!

Mark

[Valgrind-users] Fwd: thread not created when program executed with valgrind

[JD S. <sid...@gm...>]

Le mer. 17 janv. 2024 à 02:02, Paul Floyd <pj...@wa...> a écrit :

>
>
> Not much has changed to the threading/scheduling, unless you are
> changing the thread attributes for priority/scheduling. If so then you
> should try Valgrind 3.22.
>
> Otherwise, try
>
> --fair-sched=yes
>
>
Thank you for your answer.

Unfortunately, I'm stuck with valgrind 3.19 for some reason.

I'm not modifying any thread priorities or scheduling.

Before your answer, I tried a couple of things. And I discovered that if I
create a non-member function
that will call Class::MemberFunction, and use that 'global' function as the
thread entry point, then the
thread is created and executed...

So, creating the thread with a line like:

auto thread = new std::thread(NonMemberFunction, this, ptr1, ptr2);

and with

void
NonMemberFunction(Class *ptr_to_instance, Ptr1 *ptr1, Ptr2 *ptr2)
{
   ptr_to_instance->MemberFunction(ptr1, ptr2);
}

will work...

Hope that could be useful if other people face the same thing.

So the problem looks to be related to issues with creating threads with
bound member functions.

I'll try the --fair-sched=yes option and keep posted here in case that
fixes the issue.

Cheers.

Re: [Valgrind-users] thread not created when program executed with valgrind

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

On 16/01/2024 20:17, JD Silence wrote:
> Hello,
>
> I'm looking for some hints, advice and any other things that could 
> help me figure this out.
>
> I have a big program which I wanted to debug some memory issues. This 
> program internally creates and runs several threads.
>
[snip]
> The program is written in C++ 20. That particular problematic thread 
> is simply created by a line like:
>
> auto thread = new std::thread(&Class::MemberFunction, this, ptr1, ptr2);
>
> So nothing fancy, in my opinion. The debugger reaches that line, and a 
> press to next never enters the breakpoint set in Class::MemberFunction.
>
> In case that could matter, I'm using valgrind 3.19.0 on Debian 12.
>

Not much has changed to the threading/scheduling, unless you are 
changing the thread attributes for priority/scheduling. If so then you 
should try Valgrind 3.22.

Otherwise, try

--fair-sched=yes


A+

Paul

[Valgrind-users] thread not created when program executed with valgrind

[JD S. <sid...@gm...>]

Hello,

I'm looking for some hints, advice and any other things that could help me
figure this out.

I have a big program which I wanted to debug some memory issues. This
program internally creates and runs several threads.

But when launched with valgrind, one of the threads is not created.

Attaching gdb with valgrind, I can break on the line creating the thread, I
can add a breakpoint in that thread function, but it never reaches the
thread function. All other threads are well created and run.

Without valgrind, the thread is well created and runs well. Both with and
without gdb, with and without debugging symbols.

In general, the main program runs well, and never faces issues with
threads. It just exposes some memory issues with a particular dataset which
I want to debug.

The program is written in C++ 20. That particular problematic thread is
simply created by a line like:

auto thread = new std::thread(&Class::MemberFunction, this, ptr1, ptr2);

So nothing fancy, in my opinion. The debugger reaches that line, and a
press to next never enters the breakpoint set in Class::MemberFunction.

In case that could matter, I'm using valgrind 3.19.0 on Debian 12.

Thank you in advance.

[Valgrind-users] A thousand bugs

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

Hi all,

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.

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

[Valgrind-users] Valgrind-3.22.0 is available

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

We are pleased to announce a new release of Valgrind, version 3.22.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 and
AMD64/FreeBSD.  There is also preliminary support for X86/macOS 10.13,
AMD64/macOS 10.13 and nanoMIPS/Linux.

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

* A new configure option --with-gdbscripts-dir lets you install
  the gdb valgrind python monitor scripts in a specific location.
  For example a distro could use it to install the scripts in a
  safe load location --with-gdbscripts-dir=%{_datadir}/gdb/auto-load
  It is also possible to configure --without-gdb-scripts-dir so no
  .debug_gdb_scripts section is added to the vgpreload library and
  no valgrind-monitor python scripts are installed at all.

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

* Support has been added for FreeBSD 14 and FreeBSD 15.
* Add support for the folllowing FreeBSD system calls:
  close_range, kqueuex, membarrier, timerfd_create,
  timerfd_settime and timerfd_gettime (all added in FreeBSD 15).

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

* Memcheck now tests and warns about the values used for
  alignment and size. These apply to various functions: memalign,
  posix_memalign and aligned_alloc in C and various overloads
  of operators new and delete in C++. The kinds of error that can
  be detected are
  - invalid alignment, for instance the alignment is usually required
    to be a power of 2
  - mismatched alignment between aligned allocation and aligned
    deallocation
  - mismatched size when sized delete is used
  - bad size for functions that have implementation defined behaviour
    when the requested size is zero

* Cachegrind:
  - You can now profile part of a program's execution using the new
    `CACHEGRIND_START_INSTRUMENTATION` and `CACHEGRIND_STOP_INSTRUMENTATION`
    client requests, along with the new `--instr-at-start` option. The
    behaviour is the same as Callgrind's equivalent functionality.

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

390871  ELF debug info reader confused with multiple .rodata* sections
417993  vbit-test fail on s390x with Iop_Add32: spurious dependency on uninit
426751  Valgrind reports "still reachable" memory using musl
        (alpine running inside docker)
432801  Valgrind 3.16.1 reports a jump based on uninitialized memory somehow
        related to clang and signals
433857  Add validation to C++17 aligned new/delete alignment size
433859  Add mismatched detection to C++ 17 aligned new/delete
460192  Add epoll_pwait2
461074  DWARF2 CFI reader: unhandled DW_OP_ 0x11 (consts) DW_OP_ 0x92 (bregx)
465782  s390x: Valgrind doesn't compile with Clang on s390x
466105  aligned_alloc problems, part 2
467441  Add mismatched detection to C++ 14 sized delete
469049  link failure on ppc64 (big endian) valgrind 3.20
469146  massif --ignore-fn does not ignore inlined functions
469768  Make it possible to install gdb scripts in a different location
470121  Can't run callgrind_control with valgrind 3.21.0 because of perl errors
470132  s390x: Assertion failure on VGM instruction
470520  Multiple realloc zero errors crash in MC_(eq_Error)
470713  Failure on the Yosys project: valgrind: m_libcfile.c:1802
        (Bool vgPlain_realpath(const HChar *, HChar *)):
        Assertion 'resolved' failed
470830  Don't print actions vgdb me ... continue for vgdb --multi mode
470978  s390x: Valgrind cannot start qemu-kvm when "sysctl vm.allocate_pgste=0"
471311  gdb --multi mode stdout redirecting to stderr
471807  Add support for lazy reading and downloading of DWARF debuginfo
472219  Syscall param ppoll(ufds.events) points to uninitialised byte(s)
472875  none/tests/s390x/dfp-1 failure 
472963  Broken regular expression in configure.ac
473604  Fix bug472219.c compile failure with Clang 16
473677  make check compile failure with Clang 16 based on GCC 13.x
473745  must-be-redirected function - strlen
473870  FreeBSD 14 applications fail early at startup
473944  Handle mold linker split RW PT_LOAD segments correctly
474332  aligned_alloc under Valgrind returns nullptr when alignment is not a multiple of sizeof(void *)
475650  DRD does not work with C11 threads
475652  Missing suppression for __wcsncpy_avx2 (strncpy-avx2.S:308)?
476108  vg_replace_malloc DELETE checks size
n-i-bz  Allow arguments with spaces in .valgrindrc files
n-i-bz  FreeBSD fixed reading of Valgrind tools own debuginfo

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.22.0.RC1: 17 Oct 2023)
(3.22.0.RC2: 26 Oct 2023)

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

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

On 26-10-23 14:48, Mark Wielaard wrote:
> An RC2 tarball for 3.22.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2
> (md5sum = 07bb18b0fd1c7347b350d8d71dc940f6)
> (sha1sum = 61c29e47efdc933ea3f23cb2f0fcebcd6d96dab1)
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2.asc

First, a non-blocking issue
https://bugs.kde.org/show_bug.cgi?id=476320
I'll deal with that after the release

Overall looks OK.

Here are my results:

FreeBSD 13.2 amd64
== 841 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 
0 stdoutB failures, 0 post failures ==

FreeBSD 13.2 x86
== 772 tests, 8 stderr failures, 0 stdout failures, 0 stderrB failures, 
2 stdoutB failures, 0 post failures ==

FreeBSD 12.4 x86
== 768 tests, 7 stderr failures, 0 stdout failures, 1 stderrB failure, 2 
stdoutB failures, 0 post failures ==

FreeBSD 12.4 amd64
== 833 tests, 7 stderr failures, 0 stdout failures, 1 stderrB failure, 1 
stdoutB failure, 0 post failures ==

FreeBSD 14.0 RC3 amd64
== 836 tests, 8 stderr failures, 0 stdout failures, 0 stderrB failures, 
1 stdoutB failure, 0 post failures ==

FreeBSD 14.0 RC3 x86
== 771 tests, 11 stderr failures, 0 stdout failures, 0 stderrB failures, 
2 stdoutB failures, 0 post failures ==

Soalaris 11,3 amd64
== 852 tests, 16 stderr failures, 1 stdout failure, 1 stderrB failure, 0 
stdoutB failures, 9 post failures ==

Illumos (OpenIndiana Hipster 2023.10) amd64
== 858 tests, 79 stderr failures, 16 stdout failures, 18 stderrB 
failures, 20 stdoutB failures, 6 post failures ==

Alpine 3.19 amd64
== 645 tests, 97 stderr failures, 27 stdout failures, 5 stderrB 
failures, 5 stdoutB failures, 5 post failures ==
No change

Alpine 3.19 x86
== 652 tests, 121 stderr failures, 33 stdout failures, 1 stderrB 
failure, 4 stdoutB failures, 5 post failures ==

macOS
== 734 tests, 327 stderr failures, 91 stdout failures, 0 stderrB 
failures, 0 stdoutB failures, 34 post failures ==


A+
Paul

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

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

Hi Eyal,

On Fri, 2023-10-27 at 21:44 -0600, Eyal Soha wrote:
> I have uploaded two possible fixes but I'm unable to test them.  If someone is able to reproduce this bug faithfully, can you try each patch below and let me know if it works?  You can apply the patch with `git am <filename>'.
> 
> Download these:
> 
> https://bugs.kde.org/attachment.cgi?id=162607 (I prefer this one.)
> https://bugs.kde.org/attachment.cgi?id=162608 (If that one doesn't work, maybe this one?)

Very nice analysis. I put some comments in the bug, but in general I
think you found (and fixed) the issue.

> To test, you can run this:
> 
> ./autogen.sh && ./configure && make -j 20 && make -j 20 check && valgrind -q --expensive-definedness-checks=yes memcheck/tests/vbit-test/vbit-test

vbit-test for s390x needs to run from the actual memcheck/tests/vbit-
test (see the source, there is a system call to S390X_FEATURES in it).
But if you run it (with you patch) it works as intended:

$ ../../../vg-in-place --expensive-definedness-checks=yes ./vbit-test 
==2242090== Memcheck, a memory error detector
==2242090== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2242090== Using Valgrind-3.22.0.RC2 and LibVEX; rerun with -h for copyright info
==2242090== Command: ./vbit-test
==2242090== 
==2242090== 
==2242090== HEAP SUMMARY:
==2242090==     in use at exit: 0 bytes in 0 blocks
==2242090==   total heap usage: 256 allocs, 256 frees, 104,448 bytes allocated
==2242090== 
==2242090== All heap blocks were freed -- no leaks are possible
==2242090== 
==2242090== For lists of detected and suppressed errors, rerun with: -s
==2242090== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

and even with the system valgrind:

$ valgrind --expensive-definedness-checks=yes ./vbit-test 
==2242137== Memcheck, a memory error detector
==2242137== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2242137== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==2242137== Command: ./vbit-test
==2242137== 
==2242137== 
==2242137== HEAP SUMMARY:
==2242137==     in use at exit: 0 bytes in 0 blocks
==2242137==   total heap usage: 256 allocs, 256 frees, 104,448 bytes allocated
==2242137== 
==2242137== All heap blocks were freed -- no leaks are possible
==2242137== 
==2242137== For lists of detected and suppressed errors, rerun with: -s
==2242137== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Thanks,

Mark

Re: [Valgrind-users] valgrind usage in arm board

[ramakanth v. <ram...@gm...>]

Hi John,

Thanks a lot for your references ,  below is  valgrind bug filed.

https://bugs.kde.org/show_bug.cgi?id=476277.

Will post further details as I explore.

Thanks
vlrk

On Sat, Sep 30, 2023 at 5:15 AM John Reiser <jr...@bi...> wrote:

> On 9/28/23 20:55, ramakanth varala wrote:
> > I gathered all info at this place https://pastebin.com/1sekb62v <
> https://pastebin.com/1sekb62v>
>
> Looking at the previous messages of the thread in [Valgrind-users] mailing
> list,
> I don't see any information about the context in which you are working.
> Specifically:
>    Which version of valgrind ?  (Run "valgrind --version".)
>    Which hardware?
>    Which operating system and version?
>    Which Linux distribution and software [cross-]development environment?
>    Which compiler and version, and which C run-time library and version?
>
> Some of that info is *required* in order to help you,
> and all of it makes it much easier for maintainers
> to understand what the problem might be.
>
>  From the pastebin posting it apears that you are running Linux
> on a 32-bit ARM system which uses /lib/ld-linux.so.3 as the
> run-time dynamic linker.  But which version of the development
> environment, compiler, and run-time C library?  Yes, it might
> really matter.  Bottom line: give enough information so that
> a maintainer can reproduce the problem that you see.
>
> Getting down to specifics:
> > $ readelf --use-dynamic --symbols ./lib/ld-linux.so.3  >
> /home/labuser/rk/symbols-2.txt
> The use of "./lib/ld-linux.so.3" instead of "/lib/ld-linux.so.3"
> [the difference is a leading dot '.' or not] triggers alarm bells.
> You must be *ABSOLUTELY CERTAIN* that those two files have
> identical contents.  Particularly with "cross-system" environments,
> it is trivially easy for them to differ inadvertently or on purpose.
> Run both 'cmp' and 'sha256sum' to be sure that the contents are the same.
> If the contents are not the same, then you must start over from the
> beginning.
>
> Using a text editor on the contents of the pastebin posting:
> =====
> :g/index$/p
>     857: 0001a300   204 FUNC    LOCAL  DEFAULT   10 index
>
> :g/index$/?Symbol table?p
> Symbol table '.symtab' contains 988 entries:
>
> :g/index$/?$ cat?p
> $ cat /home/labuser/rk/symbols-1.txt
> =====
> Therefore the symbol 'index' does exist in the link-time symbols-1.txt,
> but not in the run-time symbol table symbols-2.txt.  So if the real
> /lib/ld-linux.so.3 has been stripped in order to save space, then
> 'index' will disappear, and valgrind will not be able to find it.
>
> =====
> :g/strchr$/p
>     933: 0001a300   204 FUNC    LOCAL  DEFAULT   10 strchr
>
> :g/strchr$/?Symbol table?p
> Symbol table '.symtab' contains 988 entries:
>
> :g/strchr$/?$ cat?p
> $ cat /home/labuser/rk/symbols-1.txt
> =====
> Therefore 'strchr' is a synonym for 'index', having the same value
> 0x0001a300 and the same properties, but a different name, and a
> different position in the link-time symbol table.
>
> Overall conclusion: you have found a bug in valgrind,
> namely 'index' is optional, and not required as demanded by valgrind.
> (Which version of valgrind?  :-) )
> Please file a bug report, following the directions at
>     https://valgrind.org/support/bug_reports.html
> You will need to supply all the version info of the various pieces,
> and the analysis of which symbols really are present, and _where_.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

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

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

> On 27 Oct 2023, at 00:54, Mark Wielaard <ma...@kl...> wrote:
> 
> Thanks.
> 
> = I ran make regtest on Fedora 38 POWER9 ppc64le and got:
> 
> == 732 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
> memcheck/tests/bug340392                 (stderr)
> drd/tests/std_thread2                    (stderr)
> 
> --- std_thread2.stderr.exp      2023-04-27 15:25:16.109185858 +0000
> +++ std_thread2.stderr.out      2023-10-26 23:12:41.571112420 +0000
> @@ -1,9 +1,14 @@
> 
> Thread 2:
> +Conflicting load by thread 2 at 0x........ size 8
> +   at 0x........: _dl_new_hash (dl-new-hash.h:90)
> +   by 0x........: _dl_lookup_symbol_x (dl-lookup.c:757)
> +Allocation context: Data section of /usr/lib64/ld64.so.2
> +
> Conflicting store by thread 2 at 0x........ size 4
>    at 0x........: main::LAMBDA::operator()() const (std_thread2.cpp:21)
> Allocation context: BSS section of std_thread2
> 
> Done.
> 
> -ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> +ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0)
> 
> I haven't really looked into that more. It is a deterministic
> failure. But I think data races in ld.so should be suppressed?

That’s right. Any non-pthread locking mechanisms in libc libpthread ld.so that generates errors should be suppressed (we assume that these libraries are correct, they would need annotation otherwise).

A+
Paul

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

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

Hi,

On Thu, Oct 26, 2023 at 12:38:04PM -0700, Carl Love via Valgrind-developers wrote:
> Valgrind-3.22.0.RC2 looks good on power. I have run the RC2 on Power
> 10LE, Power 9 LE, Power 8 LE/BE, and Power 7 BE. I see the two failures
> 
> memcheck/tests/bug340392                 (stderr)
> memcheck/tests/linux/rfcomm              (stderr)
> 
> everywhere which is normal.  A couple of the older systems also report
> 
> memcheck/tests/leak_cpp_interior         (stderr)
> memcheck/tests/linux/sys-execveat        (stderr)
> 
> which is also consistent on those platforms.
> 
> It all looks good on PowerPC.

Thanks.

= I ran make regtest on Fedora 38 POWER9 ppc64le and got:

== 732 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/bug340392                 (stderr)
drd/tests/std_thread2                    (stderr)

--- std_thread2.stderr.exp      2023-04-27 15:25:16.109185858 +0000
+++ std_thread2.stderr.out      2023-10-26 23:12:41.571112420 +0000
@@ -1,9 +1,14 @@
 
 Thread 2:
+Conflicting load by thread 2 at 0x........ size 8
+   at 0x........: _dl_new_hash (dl-new-hash.h:90)
+   by 0x........: _dl_lookup_symbol_x (dl-lookup.c:757)
+Allocation context: Data section of /usr/lib64/ld64.so.2
+
 Conflicting store by thread 2 at 0x........ size 4
    at 0x........: main::LAMBDA::operator()() const (std_thread2.cpp:21)
 Allocation context: BSS section of std_thread2
 
 Done.
 
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0)

I haven't really looked into that more. It is a deterministic
failure. But I think data races in ld.so should be suppressed?

= On Fedora 40 (rawhide) x86 (32bit) here are zero failures !

= On Fedora 38 s390x

== 842 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failure, 0 stdoutB failure, 0 post failures ==
memcheck/tests/vbit-test/vbit-test       (stderr)

--- vbit-test.stderr.exp		 2022-02-09 22:47:30.491170867 +0000
+++ vbit-test.stderr.out		 2023-10-26 22:51:38.544254194 +0000
@@ -0,0 +1,3 @@
+Conditional jump or move depends on uninitialised value(s)
+   ...
+

I believe I saw this with 3.21.0 too.

= On RHEL8 x86_64

== 880 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 9 post failures ==
memcheck/tests/overlap                   (stderr)

Which is https://bugs.kde.org/show_bug.cgi?id=402833

Cheers,

Mark

[Valgrind-users] Valgrind-3.22.0.RC2 is available for testing

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

An RC2 tarball for 3.22.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2
(md5sum = 07bb18b0fd1c7347b350d8d71dc940f6)
(sha1sum = 61c29e47efdc933ea3f23cb2f0fcebcd6d96dab1)
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2.asc

Changes since RC1:

Andreas Arnez (5):
      s390x: Fix memcheck false positives with certain comparisons
      s390x regtest: Fix memcheck tests for cu21 and cu42 with Clang
      Update NEWS to reflect Clang support for s390x
      s390x: Adjust .gitignore after commit 7cf98163adb3f
      s390x regtest: Activate 128 bit SIMD tests for s390x in vbit-test

Carl Love (3):
      Bug 476025 - Powerpc, update expected results for the vbit-test
      Revert "Bug 476025 - Powerpc, update expected results for the
vbit-test"
      Change the vbit test specification for Iop_CmpGT64Ux2

Mark Wielaard (7):
      Add new drd/tests/thrd_create test to .gitignore
      Add arm-linux build artifacts to .gitignore
      vg_replace_malloc DELETE should not check size
      Add 32bit variant of new_aligned_delete_default.stderr.exp
      Add x86 variant of origin5-bz2.stderr.exp-glibc25-amd64-b
      Add new exp files to EXTRA_DIST in memcheck/tests/Makefile.am
      Set version to 3.22.0-RC2

Please give it a try in configurations that are important for you and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind

If nothing critical emerges, a final release will happen on Tuesday 31
October.

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.22.0.RC1 is available for testing

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

Hi,

On Wed, Oct 18, 2023 at 01:04:21AM +0200, Mark Wielaard wrote:
> An RC1 tarball for 3.22.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2
> (md5sum = 786715e301f9b1d3e10faf2a5b360598)
> (sha1sum = ea0e9ca5b5c45168bfcb795e1d19d9d3f5d58223)
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2.asc
> 
> Please give it a try in configurations that are important for you and
> report any problems you have, either on this mailing list, or
> (preferably) via our bug tracker at
> https://bugs.kde.org/enter_bug.cgi?product=valgrind
> 
> RC2 will appear in one week, Tuesday 24 October. And if nothing
> critical emerges after that, a final release will happen a week after
> that on Tuesday 31 October.

I am pushing out RC2 two days to Thursday 26 October so we can get a
fix in for https://bugs.kde.org/show_bug.cgi?id=476025 It is not super
urgent since it looks like a testsuite only issue. But it would be
nice to be able to check the vbit tests correct on all arches.

Cheers,

Mark

[Valgrind-users] Valgrind-3.22.0.RC1 is available for testing

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

An RC1 tarball for 3.22.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2
(md5sum = 786715e301f9b1d3e10faf2a5b360598)
(sha1sum = ea0e9ca5b5c45168bfcb795e1d19d9d3f5d58223)
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2.asc

Please give it a try in configurations that are important for you and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind

RC2 will appear in one week, Tuesday 24 October. And if nothing
critical emerges after that, a final release will happen a week after
that on Tuesday 31 October.

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

[Karl R. <kro...@zo...>]

On Thursday, October 12, 2023 4:16:17 AM EDT Paul Floyd wrote:
> Yes, a lot of users tend to be confused in thinking that once an object
> has been initialized then it will always be initialized.

I found the problem in my code and it was as you say Paul.  Due to a bug 
elsewhere, some member in the uninitialized part of the structure was being 
used to overwrite a previously set member.

Thanks for your feedback and your continued work on Valgrind! 


-Karl

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

[Karl R. <kro...@zo...>]

On Thursday, October 12, 2023 4:16:17 AM EDT Paul Floyd wrote:
> Yes, a lot of users tend to be confused in thinking that once an object
> has been initialized then it will always be initialized.
> 
> We can't see when is happening between the possibly incomplete
> initialization and the actual error.

You can see the actual errors reported and the memset test line which 
eliminates them here:
    https://github.com/WickedSmoke/xu4/compare/valgrind?expand=1

The memset is before the actual initialization in txf_begin(), so if an 
uninitialized value were assigned later then it should not be changing the 
valgrind report.

The actual struct names are ListDrawState & TxfDrawState and both are plain 
data of 128 bytes & 72 bytes respectively.


-Karl

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

[Tom H. <to...@co...>]

On 12/10/2023 08:53, Paul Floyd wrote:
> 
> On 11/10/2023 23:47, Karl Robillard via Valgrind-users wrote:
>> I'm getting the following error on struct members which should absolutely be
>> initialized:
>>    Conditional jump or move depends on uninitialised value(s)
>>
>> To begin investigating I did a memset of zero on the entire struct and the
>> error goes away.  Now this C++ struct inherits another one and the error is
>> reported in C code expecting the base struct.  If I only memset the base
>> struct the error is still reported, which should be impossible.
>>
>> Code summary of the weirdness:
>>
>>      struct ListDrawState : public DrawState { ... };
>>      extern "C" void draw_func(DrawState*);
>>
>>      ListDrawState ds;
>>      memset(&ds, 0, sizeof(DrawState));  // Error in draw_func()
> 
> I don't think that this is legal C++. You can't assume that a C++ class 
> object has the same kind of memory layout as a POD C struct.

That's not any part of the problem code though, so it's not
really relevant to the original problem.

There's no way we can comment on the original problem though
because we can't actually see any of the code, only a few top
level highlights which is nowhere near enough to tell us
anything about what is happening.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

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

On 12/10/2023 10:06, Tom Hughes wrote:
>
> That's not any part of the problem code though, so it's not
> really relevant to the original problem.
>
> There's no way we can comment on the original problem though
> because we can't actually see any of the code, only a few top
> level highlights which is nowhere near enough to tell us
> anything about what is happening.


Yes, a lot of users tend to be confused in thinking that once an object 
has been initialized then it will always be initialized.

We can't see when is happening between the possibly incomplete 
initialization and the actual error.


Just to explain that first point, in pseudo code

Uninit x; // not initialized

Widget w;

memset w to 0;

// w now all initialized

w.thing = x;

// w.thing now uninitialized


A+

Paul

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

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

On 11/10/2023 23:47, Karl Robillard via Valgrind-users wrote:
> I'm getting the following error on struct members which should absolutely be
> initialized:
>    Conditional jump or move depends on uninitialised value(s)
>
> To begin investigating I did a memset of zero on the entire struct and the
> error goes away.  Now this C++ struct inherits another one and the error is
> reported in C code expecting the base struct.  If I only memset the base
> struct the error is still reported, which should be impossible.
>
> Code summary of the weirdness:
>
>      struct ListDrawState : public DrawState { ... };
>      extern "C" void draw_func(DrawState*);
>
>      ListDrawState ds;
>      memset(&ds, 0, sizeof(DrawState));  // Error in draw_func()

I don't think that this is legal C++. You can't assume that a C++ class 
object has the same kind of memory layout as a POD C struct.

Does this apply in your case?

https://en.cppreference.com/w/cpp/language/ebo

If ListDrawState isn't using EBO then its size will be larger DrawState 
even though it may not add any data members.


In summary, you should either stick to POD structures and then you can 
use memset or else use C++ classes and constructors.


A+

Paul