valgrind-users Mailing List for Valgrind, an open-source memory debugger (Page 7)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

On 24-04-24 23:33, Mark Wielaard wrote:
> An RC2 tarball for 3.23.0 is now available at


FreeBSD amd64 and arm64 both still fine.

A+
Paul





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

That was Android running within Termux.




On 25-04-24 08:50, Simon Sobisch wrote:
> I've compiled and tried to run the RC2 on some environments, using
> 
> 1. Find just a minor patch for configure.ac to improve help output and 
> keep the style of the file (two missing spaces visible in "configure 
> --help"; tabs/line breaks).
> 
> 2. One thing that _may_ be an old issue: all the make targets check, 
> regtest and perf fail because of missing g++ on building "bug464969", 
> while configure and make pass.

> 
> 3. "make regtest" fails in my out-of-tree build (where "make check" 
> executed without errors)
> 
> ../gdbserver_tests/make_local_links /usr/bin/gdb
> if /usr/bin/perl tests/vg_regtest gdbserver_tests memcheck cachegrind 
> callgrind helgrind drd massif dhat lackey none exp-bbv ; then \
>     tests/post_regtest_checks /home/build/valgrind-3.23.0.RC2/build/.. 
> gdbserver_tests memcheck cachegrind callgrind helgrind drd massif dhat 
> lackey none exp-bbv; \
> else \
>     tests/post_regtest_checks /home/build/valgrind-3.23.0.RC2/build/.. 
> gdbserver_tests memcheck cachegrind callgrind helgrind drd massif dhat 
> lackey none exp-bbv; \
>     false; \
> fi
> sh: 0: cannot open 
> /home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
> sh: 0: cannot open 
> /home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
> sh: 0: cannot open 
> /home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
> sh: 0: cannot open 
> /home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
> -- Running  tests in memcheck/tests/linux ------------------------------
> vg_regtest: `./filter_stderr' not found or not a file (.)
> /bin/bash: line 4: tests/post_regtest_checks: No such file or directory
> make: *** [Makefile:1442: regtest] Error 1
> 
> 
> 4. "make perf" outputs
> == 0 programs, 0 timings =================

Hi

I'll apply the configure patch after the release.

Not having a C++ compiler. I can just about imagine someone building and 
using Valgrind without a C++ compiler - in some situations it might make 
automatic package building faster. Is there any benefit to being able to 
run only the non-C++ testcases?

It's a while since I tried an out of tree build. There is a bugzilla 
item for that https://bugs.kde.org/show_bug.cgi?id=333628

What platform did you use for "make perf"?

A+
Paul




On 25-04-24 14:39, Simon Sobisch wrote:
> 1. Several failing tests because of sed and ps usage. With
>
> 2.  Two failing tests on Debian with AMD Ryzen:

> 3. compile warnings with clang on arm64 (in multiple files/positions 
> with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, 
> CALL_FN_W_WWW and CALL_FN_W_WWWW):



Hi

Thanks for the tests.

sed, ps etc. I don't think that it's worth adding checks but we should 
add something to README_DEVELOPERS. It's a similar situation on FreeBSD 
and Illumos, documented in their respective READMEs.

Regtest fails. stime is deprecated, but that shouldn't change things.
The permission messages - I'll see if I can reproduce on another machine.

For the arm64 warnings, what OS were you usung?

The last two warnings I'll deal with after the release.

A+
Paul



Mark:

RC2 fixes a number of failures from RC1.  I think it RC2 is good to go.

Power 10
memcheck/tests/linux/rfcomm              (stderr)    Also failed for valgrind 3.22.0

Power 9
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

Power8LE
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

Power8BE
memcheck/tests/leak_cpp_interior         (stderr)    Also failed for valgrind 3.22.0
none/tests/socket_close                  (stderr)    Didn't see this one fail for 3.22.0 but it did
                                                     for some of the other platforms.  So maybe it
                                                     is a little noisy.  I don't think it is an issue.

Ship it!

                           Carl 

On 4/24/24 16:33, Mark Wielaard wrote:
> An RC2 tarball for 3.23.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2
> (md5sum = c1540fb2d48648666f1479d3e44154be)
> (sha1sum = 85438bfae1e03a42cacda0a7a4071c49eaa97f96)
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2.asc
> 
> Changes since RC1
> 
> Andreas Arnez (1):
>   s390x: Improve operand names in trackers for PRNO
> 
> Mark Wielaard (11):
>   32 bit new_delete_mismatch_size and sized_aligned_new_delete_misaligned .exp
>   Add new .exp-32 files to memcheck/tests/Makefile.am EXTRA_DIST
>   filter out in /absolute/path in drd/tests stderr filter
>   Filter away "main" differences in filter_fdleak
>   VG_(show_open_fds) Only emit empty line when not creating xml output
>   Add dl_new_hash suppression to drd/tests/std_thread2.supp
>   Add another drd/tests/bar_bad exp variant.
>   Add new bar_bad exp files to drd/tests/Makefile.am (EXTRA_DIST).
>   Add prereqs for tests using python 3.9+
>   glibc-2.X-helgrind.supp.in: Also recognize variants on gethostbyname2_r
>   Set version to 3.23.0-RC2
> 
> Paul Floyd (6):
>   FreeBSD suppression: add a suppression for __swbuf seen on arm64
>   FreeBSD suppression: reachable for setlocale
>   FreeBSD suppressions: yet more reachables
>   FreeBSD suppression: puts reachable
>   FreeBSD syswrap: wrong length for __sysctlbyname(name)
>   FreeBSD syscall: add wrapper for kcmp
> 
> 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
> Friday 26 April.
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



1. Several failing tests because of sed and ps usage. With

sed --version
This is not GNU sed version 4.0
BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary.

There are a bunch of

	sed: unsupported command ,

messages during "make regtest" so the result is not usable

similar with ps
BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary.

raising
	ps: unrecognized option: p


Ideally configure would check for the used options and raise a warning 
that the tests cannot be run, "make regtest" and friends could run a 
pre-target that tries to execute those tools as well.


2.  Two failing tests on Debian with AMD Ryzen:

== 895 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 
0 stdoutB failures, 0 post failures ==
memcheck/tests/x86-linux/scalar          (stderr)
none/tests/scripts/shell                 (stderr)

--- scalar.stderr.exp   2024-04-25 00:46:46.000000000 +0200
+++ scalar.stderr.out   2024-04-25 13:18:57.456992272 +0200
@@ -224,7 +224,7 @@
     ...
     by 0x........: main (scalar.c:97)
   Address 0x........ is on thread 1's stack
- in frame #1, created by main (scalar.c:29)
+ in frame #2, created by main (scalar.c:29)

  Syscall param execve(argv[0]) points to unaddressable byte(s)
     ...
@@ -255,7 +255,7 @@
     ...
     by 0x........: main (scalar.c:100)
   Address 0x........ is on thread 1's stack
- in frame #1, created by main (scalar.c:29)
+ in frame #2, created by main (scalar.c:29)

  Syscall param execve(envp[i]) points to unaddressable byte(s)
     ...
@@ -404,3828 +404,4 @@
  -----------------------------------------------------
   24:         __NR_getuid 0s 0m
  -----------------------------------------------------
------------------------------------------------------
- 25:          __NR_stime n/a
------------------------------------------------------
[more]
-
+scalar: scalar.c:152: main: Assertion `-1 != res' failed.

and

--- shell.stderr.exp    2024-04-25 00:46:46.000000000 +0200
+++ shell.stderr.out    2024-04-25 13:26:20.796944128 +0200
@@ -1,8 +1,8 @@
-./shell: ./x86/: is a directory
-./shell: ./shell.vgtest: Permission denied
+./shell: 10: ./x86/: Permission denied
+./shell: 13: ./shell.vgtest: Permission denied
  execve(0x........(./shell_badinterp), 0x........, 0x........) failed, 
errno 2
  EXEC FAILED: I can't recover from execve() failing, so I'm dying.
  Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell: ./shell_binaryfile: cannot execute binary file
-./shell: ./shell_nosuchfile: No such file or directory
-./shell: shell_nosuchfile: command not found
+./shell: 19: ./shell_binaryfile: Exec format error
+./shell: 22: ./shell_nosuchfile: not found
+./shell: 25: shell_nosuchfile: Permission denied


3. compile warnings with clang on arm64 (in multiple files/positions 
with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, 
CALL_FN_W_WWW and CALL_FN_W_WWWW):

warning: inline asm clobber list contains reserved registers: X18 
[-Winline-asm]
    74 |    CALL_FN_W_W(ret, fn, guard);
       |    ^
../include/valgrind.h:4339:10: note: expanded from macro 'CALL_FN_W_W'
  4339 |          VALGRIND_ALIGN_STACK                                     \
       |          ^
../include/valgrind.h:4304:7: note: expanded from macro 
'VALGRIND_ALIGN_STACK'
  4304 |       "mov x21, sp\n\t"                    \
       |       ^
note: Reserved registers on the clobber list may not be preserved across 
the asm statement, and clobbering them may lead to undefined behaviour.
../include/valgrind.h:4339:10: note: expanded from macro 'CALL_FN_W_W'
  4339 |          VALGRIND_ALIGN_STACK                                     \
       |          ^
../include/valgrind.h:4304:7: note: expanded from macro 
'VALGRIND_ALIGN_STACK'
  4304 |       "mov x21, sp\n\t"                    \
       |       ^

together with

m_coredump/coredump-elf.c:775:17: warning: variable 'name' set but not 
used [-Wunused-but-set-variable]
   775 |    const HChar* name;
       |                 ^
m_debuginfo/readdwarf3.c:3121:14: warning: variable 'n_attrs' set but 
not used [-Wunused-but-set-variable]
  3121 |       Int    n_attrs     = 0;



BTW - FYI: no failures on Rocky9 with some Intel processor






I've compiled and tried to run the RC2 on some environments, using

mkdir build
cd build
../configure --enable-lto
make -j8
make -j8 check
make regtest
make perf

and think I've found some things related to the build system (and/or 
documentation).


1. Find just a minor patch for configure.ac to improve help output and 
keep the style of the file (two missing spaces visible in "configure 
--help"; tabs/line breaks).


2. One thing that _may_ be an old issue: all the make targets check, 
regtest and perf fail because of missing g++ on building "bug464969", 
while configure and make pass.


The configure script notes a bunch of "not working" parts related to CXX 
as it tests for the appropriate g++ but even if it doesn't find any 
still do all CXX tests:

configure:5587: checking for g++
configure:5622: result: no
configure:5587: checking for c++
configure:5622: result: no
configure:5587: checking for gpp
configure:5622: result: no
--
configure:5587: checking for clang++
configure:5622: result: no
configure:5646: checking for C++ compiler version
configure:5655: g++ --version >&5
../configure: eval: line 5657: g++: Permission denied
configure:5666: $? = 127
configure:5655: g++ -v >&5
../configure: eval: line 5657: g++: Permission denied
configure:5666: $? = 127
configure:5655: g++ -V >&5
../configure: eval: line 5657: g++: Permission denied
configure:5666: $? = 127
configure:5655: g++ -qversion >&5
../configure: eval: line 5657: g++: Permission denied
configure:5666: $? = 127
configure:5670: checking whether the compiler supports GNU C++
configure:5690: g++ -c   conftest.cpp >&5
../configure: eval: line 2083: g++: Permission denied
configure:5690: $? = 127
configure:5711: checking whether g++ accepts -g
configure:5732: g++ -c -g  conftest.cpp >&5
../configure: eval: line 2083: g++: Permission denied
configure:5748: g++ -c   conftest.cpp >&5
../configure: eval: line 2083: g++: Permission denied
configure:5748: $? = 127
configure:5796: checking for g++ option to enable C++11 features
configure:5811: g++  -c   conftest.cpp >&5
../configure: eval: line 2083: g++: Permission denied
[more to come]
configure:19286: checking if g++ supports __sync_add_and_fetch
configure:19313: g++ -o conftest -m64   conftest.cpp  >&5
../configure: eval: line 2424: g++: Permission denied


As "make" did not fail I deduce that CXX is only optional, in this case 
it would be useful to:

* skip all CXX related tests in configure if it isn't found as an
   executable
* skip all g++ related tests in "make check", "make regtest", "make perf".


3. "make regtest" fails in my out-of-tree build (where "make check" 
executed without errors)

../gdbserver_tests/make_local_links /usr/bin/gdb
if /usr/bin/perl tests/vg_regtest gdbserver_tests memcheck cachegrind 
callgrind helgrind drd massif dhat lackey none exp-bbv ; then \
    tests/post_regtest_checks /home/build/valgrind-3.23.0.RC2/build/.. 
gdbserver_tests memcheck cachegrind callgrind helgrind drd massif dhat 
lackey none exp-bbv; \
else \
    tests/post_regtest_checks /home/build/valgrind-3.23.0.RC2/build/.. 
gdbserver_tests memcheck cachegrind callgrind helgrind drd massif dhat 
lackey none exp-bbv; \
    false; \
fi
sh: 0: cannot open 
/home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
sh: 0: cannot open 
/home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
sh: 0: cannot open 
/home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
sh: 0: cannot open 
/home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
-- Running  tests in memcheck/tests/linux ------------------------------
vg_regtest: `./filter_stderr' not found or not a file (.)
/bin/bash: line 4: tests/post_regtest_checks: No such file or directory
make: *** [Makefile:1442: regtest] Error 1


4. "make perf" outputs
== 0 programs, 0 timings =================


Kind regards and thank you for improving valgrind!
Simon


Am 25.04.2024 um 01:33 schrieb Mark Wielaard:
> An RC2 tarball for 3.23.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2
> (md5sum = c1540fb2d48648666f1479d3e44154be)
> (sha1sum = 85438bfae1e03a42cacda0a7a4071c49eaa97f96)
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2.asc
> 
> Changes since RC1
> 
> Andreas Arnez (1):
>    s390x: Improve operand names in trackers for PRNO
> 
> Mark Wielaard (11):
>    32 bit new_delete_mismatch_size and sized_aligned_new_delete_misaligned .exp
>    Add new .exp-32 files to memcheck/tests/Makefile.am EXTRA_DIST
>    filter out in /absolute/path in drd/tests stderr filter
>    Filter away "main" differences in filter_fdleak
>    VG_(show_open_fds) Only emit empty line when not creating xml output
>    Add dl_new_hash suppression to drd/tests/std_thread2.supp
>    Add another drd/tests/bar_bad exp variant.
>    Add new bar_bad exp files to drd/tests/Makefile.am (EXTRA_DIST).
>    Add prereqs for tests using python 3.9+
>    glibc-2.X-helgrind.supp.in: Also recognize variants on gethostbyname2_r
>    Set version to 3.23.0-RC2
> 
> Paul Floyd (6):
>    FreeBSD suppression: add a suppression for __swbuf seen on arm64
>    FreeBSD suppression: reachable for setlocale
>    FreeBSD suppressions: yet more reachables
>    FreeBSD suppression: puts reachable
>    FreeBSD syswrap: wrong length for __sysctlbyname(name)
>    FreeBSD syscall: add wrapper for kcmp
> 
> 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
> Friday 26 April.
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
An RC2 tarball for 3.23.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2
(md5sum = c1540fb2d48648666f1479d3e44154be)
(sha1sum = 85438bfae1e03a42cacda0a7a4071c49eaa97f96)
https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2.asc

Changes since RC1

Andreas Arnez (1):
  s390x: Improve operand names in trackers for PRNO

Mark Wielaard (11):
  32 bit new_delete_mismatch_size and sized_aligned_new_delete_misaligned .exp
  Add new .exp-32 files to memcheck/tests/Makefile.am EXTRA_DIST
  filter out in /absolute/path in drd/tests stderr filter
  Filter away "main" differences in filter_fdleak
  VG_(show_open_fds) Only emit empty line when not creating xml output
  Add dl_new_hash suppression to drd/tests/std_thread2.supp
  Add another drd/tests/bar_bad exp variant.
  Add new bar_bad exp files to drd/tests/Makefile.am (EXTRA_DIST).
  Add prereqs for tests using python 3.9+
  glibc-2.X-helgrind.supp.in: Also recognize variants on gethostbyname2_r
  Set version to 3.23.0-RC2

Paul Floyd (6):
  FreeBSD suppression: add a suppression for __swbuf seen on arm64
  FreeBSD suppression: reachable for setlocale
  FreeBSD suppressions: yet more reachables
  FreeBSD suppression: puts reachable
  FreeBSD syswrap: wrong length for __sysctlbyname(name)
  FreeBSD syscall: add wrapper for kcmp

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
Friday 26 April.




> 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





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 



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



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



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)



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.





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



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.

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
>


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




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.

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

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



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 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



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.


2003	Jan	Feb	Mar (58)	Apr (261)	May (169)	Jun (214)	Jul (201)	Aug (219)	Sep (198)	Oct (203)	Nov (241)	Dec (94)
2004	Jan (137)	Feb (149)	Mar (150)	Apr (193)	May (95)	Jun (173)	Jul (137)	Aug (236)	Sep (157)	Oct (150)	Nov (136)	Dec (90)
2005	Jan (139)	Feb (130)	Mar (274)	Apr (138)	May (184)	Jun (152)	Jul (261)	Aug (409)	Sep (239)	Oct (241)	Nov (260)	Dec (137)
2006	Jan (191)	Feb (142)	Mar (169)	Apr (75)	May (141)	Jun (169)	Jul (131)	Aug (141)	Sep (192)	Oct (176)	Nov (142)	Dec (95)
2007	Jan (98)	Feb (120)	Mar (93)	Apr (96)	May (95)	Jun (65)	Jul (62)	Aug (56)	Sep (53)	Oct (95)	Nov (106)	Dec (87)
2008	Jan (58)	Feb (149)	Mar (175)	Apr (110)	May (106)	Jun (72)	Jul (55)	Aug (89)	Sep (26)	Oct (96)	Nov (83)	Dec (93)
2009	Jan (97)	Feb (106)	Mar (74)	Apr (64)	May (115)	Jun (83)	Jul (137)	Aug (103)	Sep (56)	Oct (59)	Nov (61)	Dec (37)
2010	Jan (94)	Feb (71)	Mar (53)	Apr (105)	May (79)	Jun (111)	Jul (110)	Aug (81)	Sep (50)	Oct (82)	Nov (49)	Dec (21)
2011	Jan (87)	Feb (105)	Mar (108)	Apr (99)	May (91)	Jun (94)	Jul (114)	Aug (77)	Sep (58)	Oct (58)	Nov (131)	Dec (62)
2012	Jan (76)	Feb (93)	Mar (68)	Apr (95)	May (62)	Jun (109)	Jul (90)	Aug (87)	Sep (49)	Oct (54)	Nov (66)	Dec (84)
2013	Jan (67)	Feb (52)	Mar (93)	Apr (65)	May (33)	Jun (34)	Jul (52)	Aug (42)	Sep (52)	Oct (48)	Nov (66)	Dec (14)
2014	Jan (66)	Feb (51)	Mar (34)	Apr (47)	May (58)	Jun (27)	Jul (52)	Aug (41)	Sep (78)	Oct (30)	Nov (28)	Dec (26)
2015	Jan (41)	Feb (42)	Mar (20)	Apr (73)	May (31)	Jun (48)	Jul (23)	Aug (55)	Sep (36)	Oct (47)	Nov (48)	Dec (41)
2016	Jan (32)	Feb (34)	Mar (33)	Apr (22)	May (14)	Jun (31)	Jul (29)	Aug (41)	Sep (17)	Oct (27)	Nov (38)	Dec (28)
2017	Jan (28)	Feb (30)	Mar (16)	Apr (9)	May (27)	Jun (57)	Jul (28)	Aug (43)	Sep (31)	Oct (20)	Nov (24)	Dec (18)
2018	Jan (34)	Feb (50)	Mar (18)	Apr (26)	May (13)	Jun (31)	Jul (13)	Aug (11)	Sep (15)	Oct (12)	Nov (18)	Dec (13)
2019	Jan (12)	Feb (29)	Mar (51)	Apr (22)	May (13)	Jun (20)	Jul (13)	Aug (12)	Sep (21)	Oct (6)	Nov (9)	Dec (5)
2020	Jan (13)	Feb (5)	Mar (25)	Apr (4)	May (40)	Jun (27)	Jul (5)	Aug (17)	Sep (21)	Oct (1)	Nov (5)	Dec (15)
2021	Jan (28)	Feb (6)	Mar (11)	Apr (5)	May (7)	Jun (8)	Jul (5)	Aug (5)	Sep (11)	Oct (9)	Nov (10)	Dec (12)
2022	Jan (7)	Feb (13)	Mar (8)	Apr (7)	May (12)	Jun (27)	Jul (14)	Aug (27)	Sep (27)	Oct (17)	Nov (17)	Dec
2023	Jan (10)	Feb (18)	Mar (9)	Apr (26)	May	Jun (13)	Jul (18)	Aug (5)	Sep (12)	Oct (16)	Nov (1)	Dec
2024	Jan (4)	Feb (3)	Mar (6)	Apr (17)	May (2)	Jun (33)	Jul (13)	Aug (1)	Sep (6)	Oct (8)	Nov (6)	Dec (15)
2025	Jan (5)	Feb (11)	Mar (8)	Apr (20)	May (1)	Jun	Jul	Aug (9)	Sep (1)	Oct (7)	Nov (1)	Dec

valgrind-users Mailing List for Valgrind, an open-source memory debugger (Page 7)

valgrind-users — General discussion list for Valgrind users