valgrind-users — General discussion list for Valgrind users

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

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

> On 22 Apr 2024, at 20:40, Carl Love via Valgrind-users <val...@li...> wrote:
> 
> Mark:
> 
> The PowerPC test results for Valgrind 3.23.0.RC1
> 
> -----------------------------------------------------------
> Power 10, Fedora release 38 :
> 
>  memcheck/tests/linux/rfcomm              (stderr)  also fails for valgrind 3.21.0
>  helgrind/tests/getaddrinfo               (stderr)  did not fail for valgrind 3.21.0

This probably needs some suppressions. On other platforms (and libcs) getaddrinfo uses a load of non-pthread locks causing a lot of noise.

A+
Paul

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

[Carl L. <ce...@li...>]

Mark:


On 4/23/24 05:21, Mark Wielaard wrote:
> Hi Carl,
> 
> On Mon, 2024-04-22 at 11:40 -0700, Carl Love wrote:
>> The PowerPC test results for Valgrind 3.23.0.RC1
> Thanks. Looks fairly good overall. I haven't studied the rest, but ...
> 
>>   none/tests/fdleak_ipv4                   (stderr)  New failure, did not fail for valgrind 3.22.0
>>   none/tests/file_dclose                   (stderr)  New failure, did not fail for valgrind 3.22.0
>>   none/tests/socket_close                  (stderr)  New failure, did not fail for valgrind 3.22.0
> These are new tests in 3.23.0 and for some reason they "main" part of
> the stacktrace is slightly different on different systems. I tried to
> work around that with the following commit:

Agreed, I think things look good.  I don't see the three new failures as something that should block the release.  I am ok with RC1.

                       Carl 

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

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

Hi Carl,

On Mon, 2024-04-22 at 11:40 -0700, Carl Love wrote:
> The PowerPC test results for Valgrind 3.23.0.RC1

Thanks. Looks fairly good overall. I haven't studied the rest, but ...

>   none/tests/fdleak_ipv4                   (stderr)  New failure, did not fail for valgrind 3.22.0
>   none/tests/file_dclose                   (stderr)  New failure, did not fail for valgrind 3.22.0
>   none/tests/socket_close                  (stderr)  New failure, did not fail for valgrind 3.22.0

These are new tests in 3.23.0 and for some reason they "main" part of
the stacktrace is slightly different on different systems. I tried to
work around that with the following commit:

commit 04d30049bf9b4ae14262a50e8a16442e1edf75f8
Author: Mark Wielaard <ma...@kl...>
Date:   Tue Apr 23 14:14:33 2024 +0200

  Filter away "main" differences in filter_fdleak
    
  Stack traces showing where fds were created show some differences in
  the "main" function, different line numbers, or (in binary) or (below
  main). Since the precise location of the original call in the main
  function isn't the goal of these tests just filer them all out and
  replace them with a simple "main".

Which should be part of RC2 to be published tomorrow.

Cheers,

Mark

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

[Carl L. <ce...@li...>]

Mark:

The PowerPC test results for Valgrind 3.23.0.RC1

-----------------------------------------------------------
Power 10, Fedora release 38 :

  memcheck/tests/linux/rfcomm              (stderr)  also fails for valgrind 3.21.0
  helgrind/tests/getaddrinfo               (stderr)  did not fail for valgrind 3.21.0
  drd/tests/std_thread2                    (stderr)  did not fail for valgrind 3.21.0
  none/tests/socket_close                  (stderr)  did not fail for valgrind 3.21.0

  Note the following failed in valgrind 3.22.0: 

  memcheck/tests/bug340392                 (stderr)
  memcheck/tests/linux/rfcomm              (stderr)

  but do not fail for Valgrind-3.23.0.RC1 

----------------------------------------------------------------
Power 9LE, Ubuntu 20.04.6 LTS 

  Valgrind-3.23.0.RC1 failures:

  memcheck/tests/leak_cpp_interior         (stderr)   Also failed for valgrind 3.22.0 
  memcheck/tests/linux/rfcomm              (stderr)   Also failed for valgrind 3.22.0  
  memcheck/tests/linux/sys-execveat        (stderr)   Also failed for valgrind 3.22.0 
  none/tests/fdleak_ipv4                   (stderr)   New failure, did not fail for valgrind 3.22.0
  none/tests/socket_close                  (stderr)   New failure, did not fail for valgrind 3.22.0

  Note the following failed in valgrind 3.22.0:

  memcheck/tests/bug340392                 (stderr)
  memcheck/tests/leak_cpp_interior         (stderr) 

  but do not fail for Valgrind-3.23.0.RC1 

----------------------------------------------------------------
Power 8LE, Ubuntu 20.04.6 LTS

  Valgrind-3.23.0.RC1 failures:

  memcheck/tests/leak_cpp_interior         (stderr)   Also failed for valgrind 3.22.0                        
  memcheck/tests/linux/rfcomm              (stderr)   Also failed for valgrind 3.22.0                              
  memcheck/tests/linux/sys-execveat        (stderr)   New failure, did not fail for valgrind 3.22.0                      
  none/tests/fdleak_ipv4                   (stderr)   New failure, did not fail for valgrind 3.22.0                                
  none/tests/socket_close                  (stderr)   New failure, did not fail for valgrind 3.22.0  

  Note the two failures from the previous valgrind -3.22.0
         
  memcheck/tests/bug340392                 (stderr)                               
  memcheck/tests/linux/sys-execveat        (stderr) 

  but do not fail for Valgrind-3.23.0.RC1 

--------------------------------------------------------------------

Power 8BE, Red Hat Enterprise Linux Server release 7.9 (Maipo)

  Valgrind-3.23.0.RC1 failures:

  memcheck/tests/leak_cpp_interior         (stderr)  Also failed for valgrind 3.22.0
  none/tests/fdleak_ipv4                   (stderr)  New failure, did not fail for valgrind 3.22.0
  none/tests/file_dclose                   (stderr)  New failure, did not fail for valgrind 3.22.0
  none/tests/socket_close                  (stderr)  New failure, did not fail for valgrind 3.22.0
 
  Note the failure from the previous valgrind -3.22.0

  memcheck/tests/bug340392                 (stderr)

  do not fail for Valgrind-3.23.0.RC1 

--------------------------------------------------------------------------

So, seeing very consistent results across distros and PowerPC processor versions.

The diff for the four failures on Power 10 are:  

  memcheck/tests/linux/sys-execveat:

more rfcomm.stderr.diff
--- rfcomm.stderr.exp	2021-01-21 10:09:33.000000000 -0500
+++ rfcomm.stderr.out	2024-04-22 11:33:22.949419105 -0400
@@ -2,7 +2,7 @@
    ...
    by 0x........: main (rfcomm.c:53)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:45)
 
@@ -10,7 +10,7 @@
    ...
    by 0x........: main (rfcomm.c:53)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:45)
 
@@ -18,7 +18,7 @@
    ...
    by 0x........: main (rfcomm.c:53)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:45)
 
@@ -26,7 +26,7 @@
    ...
    by 0x........: main (rfcomm.c:59)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)
 
@@ -34,7 +34,7 @@
    ...
    by 0x........: main (rfcomm.c:59)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)
 
@@ -42,7 +42,7 @@
    ...
    by 0x........: main (rfcomm.c:63)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)
 
@@ -50,7 +50,7 @@
    ...
    by 0x........: main (rfcomm.c:63)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)
 
@@ -58,7 +58,7 @@
    ...
    by 0x........: main (rfcomm.c:67)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)

----------------------------------------------------------------------

helgrind/tests/getaddrinfo:

 more getaddrinfo.stderr.diff
--- getaddrinfo.stderr.exp	2023-05-16 07:21:42.000000000 -0400
+++ getaddrinfo.stderr.out	2024-04-22 11:36:08.969379829 -0400
@@ -0,0 +1,31 @@
+---Thread-Announcement------------------------------------------
+
+Thread #x was created
+   ...
+   by 0x........: pthread_create@* (hg_intercepts.c:...)
+   by 0x........: main (getaddrinfo.c:33)
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+   ...
+ Address 0x........ is in the Text segment of /usr/lib64/libnss_resolve.so.2
+   ...
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+   ...
+ Address 0x........ is in the Text segment of /usr/lib64/libnss_resolve.so.2
+   ...
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+   ...
+ Address 0x........ is in the Text segment of /usr/lib64/libnss_resolve.so.2
+   ...
+


-------------------------------------------------------------------------
drd/tests/std_thread2:

more std_thread2.stderr.diff
--- std_thread2.stderr.exp	2021-01-21 10:09:33.000000000 -0500
+++ std_thread2.stderr.out	2024-04-22 11:39:24.519333567 -0400
@@ -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)

------------------------------------------------------------------

none/tests/socket_close:

 more socket_close.stderr.diff
--- socket_close.stderr.exp	2024-04-18 09:59:55.000000000 -0400
+++ socket_close.stderr.out	2024-04-22 11:41:09.189308805 -0400
@@ -10,4 +10,4 @@
  Originally opened
    at 0x........: socket (in /...libc...)
    by 0x........: open_socket (socket_close.c:17)
-   by 0x........: main (socket_close.c:31)
+   by 0x........: (below main)

-------------------------------------------------------------------

                       Carl 
Wielaard wrote:
> An RC1 tarball for 3.23.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC1.tar.bz2
> (md5sum = 6d36fd8981d6aab7350f12cc61973be5)
> (sha1sum = 6ff57d5981d774e446853e8b166be8a3bb324601)
> https://sourceware.org/pub/valgrind/valgrind-3.23.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 next week, Wednesday 24 April. And if nothing critical
> emerges after that, a final release will happen on Friday 26 April.
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

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

Test results look fairly good on the platforms I tested.

I did fix a couple of small (testcase) issues for x86:

  32 bit new_delete_mismatch_size and sized_aligned_new_delete_misaligned .exp

and s390x:

  filter out in /absolute/path in drd/tests stderr filter

With those:

RHEL 8.9/x86-64:

== 896 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

Fedora 39/s390x

== 857 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
drd/tests/bar_bad_xml                    (stderr)
drd/tests/getaddrinfo                    (stderr)

Those two tests are flaky and not always failing.

Fedora ELN x86_64 (this distro is build with -march=x86_64-v3)

== 808 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

Debian 12.5/arm64

== 727 tests, 8 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 0 post failures ==
gdbserver_tests/hgtls                    (stdoutB)
memcheck/tests/dw4                       (stderr)
memcheck/tests/varinfo2                  (stderr)
memcheck/tests/varinfo4                  (stderr)
memcheck/tests/varinfo5                  (stderr)
memcheck/tests/varinfo6                  (stderr)
memcheck/tests/varinforestrict           (stderr)
helgrind/tests/hg05_race2                (stderr)
helgrind/tests/tc20_verifywrap           (stderr)

Almost all are backtrace issues or stack/thread frame issues like

- Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:58, in frame #x of thread x
+ Address 0x........ is on thread #x's stack
+ in frame #x, created by main (tc20_verifywrap.c:49)

Fedora 38/ppc64le

== 744 tests, 4 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
drd/tests/bar_bad                        (stderr)
drd/tests/bar_bad_xml                    (stderr)
drd/tests/std_thread2                    (stderr)
none/tests/socket_close                  (stderr)

bar_bad tests seems flaky.

drd/tests/std_thread2 might need a suppression

+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

socket_close looks like the backtrace is skipping main for some reason

    at 0x........: socket (in /...libc...)
    by 0x........: open_socket (socket_close.c:17)
-   by 0x........: main (socket_close.c:31)
+   by 0x........: (below main)


Fedora 40/i386

== 801 tests, 1 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/x86-linux/scalar          (stderr)

Debian 12.5/i686

== 798 tests, 12 stderr failures, 2 stdout failures, 0 stderrB failures, 0 stdoutB failures, 1 post failure ==
memcheck/tests/close_range               (stderr)
memcheck/tests/linux/rfcomm              (stderr)
memcheck/tests/sendmsg                   (stderr)
memcheck/tests/sized_aligned_new_delete_misaligned3_supp (stderr)
memcheck/tests/x86/insn_basic            (stdout)
memcheck/tests/x86/insn_basic            (stderr)
memcheck/tests/x86-linux/scalar          (stderr)
helgrind/tests/pth_mempcpy_false_races   (stderr)
drd/tests/bar_bad                        (stderr)
massif/tests/mmapunmap                   (post)
none/tests/fdleak_ipv4                   (stderr)
none/tests/file_dclose                   (stderr)
none/tests/socket_close                  (stderr)
none/tests/x86/insn_basic                (stdout)
none/tests/x86/insn_basic                (stderr)

Haven't analyzed fully but there are clearly more failures than on
Fedora i386. Some are just things like an extra frame:

+   at 0x........: _dl_sysinfo_int80 (in /usr/lib/i386-linux-gnu/ld-linux.so.2)

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

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

An RC1 tarball for 3.23.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC1.tar.bz2
(md5sum = 6d36fd8981d6aab7350f12cc61973be5)
(sha1sum = 6ff57d5981d774e446853e8b166be8a3bb324601)
https://sourceware.org/pub/valgrind/valgrind-3.23.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 next week, Wednesday 24 April. And if nothing critical
emerges after that, a final release will happen on Friday 26 April.

Re: [Valgrind-users] Always investigate valgrind memcheck errors [rjones@redhat.com: Re: xz backdoor]

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

On 30-03-24 11:43, Mark Wielaard wrote:
> For those of you tracking the xz backdoor:
> https://lwn.net/Articles/967180/
> 
> valgrind plays a little role in the discovery.
> 
> "Then recalled that I had seen an odd valgrind complaint in my
> automated testing of postgres, a few weeks earlier, after some package
> updates were installed."  https://lwn.net/Articles/967194/
> 
> See also the attached email, which talks about this bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=2267598
> 
> So please always take valgrind memcheck errors seriously and
> investigate them!
> 
> P.S. Sourceware isn't impacted by this xz backdoor:
> https://fosstodon.org/@sourceware/112180412918966168
> But we did reset the buildbot containers of the affected distros.

Hi Mark

I think RedHat did a good job in the circumstances. It's not easy to 
keep out bad faith attacks like this.

The call stack does look peculiar, particularly the addresses 0x6 and 
0x77AD31E59B84CFFF. It would be interesting to see if there is anything 
mapped to those addresses. 0x1FFEFFF4AF is somewhere around the client 
stack.

I suppose that a debug build would only give more information on the top 
two levels.

==746855== Invalid write of size 8
==746855==    at 0x52E8645: ??? (in /usr/lib64/liblzma.so.5.6.0)
==746855==    by 0x52CA83B: _get_cpuid (in /usr/lib64/liblzma.so.5.6.0)
==746855==    by 0x6: ???
==746855==    by 0x1FFEFFF4AF: ???
==746855==    by 0x77AD31E59B84CFFF: ???
==746855==    by 0x1FFEFFF4AF: ???
==746855==    by 0x400F253: elf_machine_rela (dl-machine.h:314)
==746855==    by 0x400F253: elf_dynamic_do_Rela (do-rel.h:147)
==746855==    by 0x400F253: _dl_relocate_object (dl-reloc.c:301)

A+
Paul

[Valgrind-users] Always investigate valgrind memcheck errors [rjones@redhat.com: Re: xz backdoor]

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

For those of you tracking the xz backdoor:
https://lwn.net/Articles/967180/

valgrind plays a little role in the discovery.

"Then recalled that I had seen an odd valgrind complaint in my
automated testing of postgres, a few weeks earlier, after some package
updates were installed."  https://lwn.net/Articles/967194/

See also the attached email, which talks about this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2267598

So please always take valgrind memcheck errors seriously and
investigate them!

P.S. Sourceware isn't impacted by this xz backdoor:
https://fosstodon.org/@sourceware/112180412918966168
But we did reset the buildbot containers of the affected distros.

Re: [Valgrind-users] Docker Support

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

Dear Paul,

Thank you so much for your quick response.
Yes definitely there's an overhead.

But I tried installation of Valgrind using the tar.gz approach.

It's working fine now in a Ubuntu based docker machine.

On Tue, Mar 5, 2024, 3:45 PM Paul Floyd via Valgrind-users <
val...@li...> wrote:

>
>
> 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 mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/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