valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Valgrind-3.26.0 is available

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

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

This release adds an upgrade to GPL version 3, build control for html
and/or pdf docs, added LibVEX_set_VexControl, removed Iop_Clz32/64 and
Iop_Ctz32/64, integrated LTP v20250930, 13 new Linux syscall wrappers,
new --modify-fds=yes, use log output protocol 6 with --xml=yes, new
--track-fds=bad, gdb qExecAndArgs packet support, rewrite of DWARF
inlined subroutine handling, new vgstack utility, handling of aligned
allocation with size of zero changed, checks for C23 free_sized and
free_aligned_sized.

See the release notes below for details of the 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. It was a busy release, with more than 400 commits
by 12 people, fixing 90 bugs.

Happy and productive debugging and profiling,

-- The Valgrind Developers

Release 3.26.0 (24 Oct 2025)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

* Upgrade to the GNU General Public License version 3.

* Control building documentation. When using make dist set the
  Makefile BUILD_DOCS to none, all or html. none, does not build any
  documentation.  all, builds all documentation. html, builds HTML
  docs but skips building PDFs. See also README_DEVELOPERS.

* New VEX API function LibVEX_set_VexControl

* The deprecated IROps: Iop_Clz32/64 and Iop_Ctz32/64 have been removed

* The Linux Test Project (LTP) integration has been updated to
  v20250930. The test output has been made compatible with bunsen.
  Various issues with the linux syscall wrappers have been fixed.

  New Linux syscall wrappers for: cachestat, futex_waitv, listmount,
  mount_setattr, mseal, quotactl_fd, remap_file_pages, setdomainname,
  statmount, swapoff, swapon, sysfs and ustat.

* --modify-fds=yes has been added. It acts like --modify-fds=high (the
  highest available file descriptor is returned first) except when
  when the lowers stdin/stdout/stderr (file descriptors 0, 1, 2) are
  available. With --modify-fds=yes 0, 1 or 2 are always returned first
  when still available before higher file descriptor numbers are.

* With --xml=yes log output protocol 6 is now always used (unlike
  protocol 5 which was only used with--track-fds). The main difference
  is that the xml output now contains error summaries. See also
  xml-output-protocol6.txt.

* Add "bad" option for --track-fds. When --track-fds=bad is specified,
  do not produce errors about unclosed file descriptors at program
  exit. Only produce errors for bad file descriptor usage, either
  double close or use of file descriptor that is (no longer) valid.

* vgdb will now handle the qExecAndArgs packet.

* DWARF inlined subroutine handling has been rewritten to work cross
  compile units. This should get rid of backtraces with
  "UnknownInlinedFun".

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

FreeBSD 15 (which is expected to ship in December 2025, after
Valgrind 3.26 is released) contains a change to ptrace that affects
use of Valgrind with vgdb. This impacts the mechanism that vgdb
uses to interrupt Valgrind if all threads are blocked and you want
to get back to the gdb prompt by hitting ctrl-c. This mechanism
is no longer reliable. On arm64 Valgrind will crash with an assert.
On amd64 syscalls may give spurious and incorrect return codes.

There is a workaround. Run the following command (as root).

 sysctl debug.ptrace_attach_transparent=0

 See also
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290008

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

* There is a new utility script, "vgstack". It has two
  option, -h for minimal help, and -v for the version information.
  In normal use pass it the PID of a running Valgrind process
  and it will perform a vgdb attach and print the backtrace(s)
  of the guest executable.

* Memcheck handling of aligned allocation functions with a
  size of zero has changed.

  Firstly, 'free_aligned_sized' with a size of
  zero is no longer considered an error. This was intended so
  that deallocation had the same behaviour as allocation. In
  practice, platforms that allow aligned allocation with a
  size of zero will already generate an error at allocation.
  Other platforms will get an 'Invalid free' error. The case
  where the allocation and deallocation sizes are different
  with the deallocation size being zero is already covered by
  "Mismatched [alloc/dealloc] size" errors.

  Secondly, the three C aligned allocation functions memalign,
  aligned_alloc and posix_memalign have a different error message if
  used with a size of zero. Previously the error was "[function]
  invalid size value: [number]". This was an overstatement of the
  issue. The problem is that such usage is not portable across
  platforms. memalign and aligned_alloc are poorly documented, saying
  things like "Behavior is undefined if size is not an integral
  multiple of alignment.". Clearly this does not include negative
  integers though it does not say so explicitly. Does that include
  zero?  posix_memalign is well documented but says that using a size
  of 0 is implementation-defined. These functions now produce an error
  "Unsafe allocation with size of zero is implementation-defined".

  The associated suppression name has also changed from "BadSize" to
  "UnsafeZeroSize".

  Checks for C23 free_sized and free_aligned_sized have been added to
  Linux. Almost no libraries support these functions yet, with
  the exception being Google tcmalloc.

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

286849  [PATCH] Interceptors for new/delete on Darwin were erroneously
        commented out in r12043
306098  s390x: Alternate opcode form for convert to/from fixed and friends
309100  s390x: Testcases for extended BFP
309554  Wrap syscall remap_file_pages (216)
331311  Valgrind shows open files in /proc/self/fd that don't work for the process
338803  Handling of dwz debug alt files or cross-CU is broken
368791  Handle swapon and swapoff syscalls as linux generic
369030  Wrap linux syscall: 171 (setdomainname)
388526  Inconsistent severity in message text: "WARNING: Serious error"
418756  MAP_FIXED_NOREPLACE mmap flag unsupported
454276  Some IPC syscalls is missing for x86 linux
476465  AArch64 ARMv8.3 LDAPR/LDAPRH/LDAPRB instructions not supported
493430  Review all syscalls that use or return (new) file descriptors
493434  Add --track-fds=bad mode (no "leak" tracking)
501741  syscall cachestat not wrapped
502359  Add --modify-fds=yes option
502968  Wrap linux specific syscalls 457 (listmount) and 458 (statmount)
503098  Incorrect NAN-boxing for float registers in RISC-V
503241  s390x: Support z17 changes to the NNPA instruction
503641  close_range syscalls started failing with 3.25.0
503677  duplicated-cond compiler warning in dis_RV64M
503817  s390x: fix 'ordered comparison of pointer with integer zero' compiler warnings
503914  mount syscall param filesystemtype may be NULL
503969  Make test results of make ltpchecks compatible with bunsen
504101  Add a "vgstack" script
504177  FILE DESCRIPTORS banner shows when closing some inherited fds
504265  FreeBSD: missing syscall wrappers for fchroot and setcred
504341  Valgrind killed by LTP syscall testcase setrlimit05
504466  Double close causes SEGV
504904  Hide "bad act handler address" warnings when -q (quiet) flag is set
504909  Hide "Bad oldset address" warnings when -q (quiet) flag is set
504919  Hide "client tried to modify addresses" warnings when -q (quiet) set
504936  Add FreeBSD amd64 sysarch subcommands AMD64_SET_TLSBASE and
        AMD64_GET_TLSBASE
505228  Wrap linux specific mseal syscall
505673  Valgrind crashes with an internal error and SIGBUS when
        the guest tries to open its own file with O_WRONLY|O_CREAT|O_TRUNC
506076  unimplemented fcntl command: 1028 (F_CREATED_QUERY)
506499  Unhandled syscall 592 (exterrctl - FreeBSD
506795  Better report which clone flags are problematic
506806  Fix execveat() with AT_FDCWD and relative path
506813  The execveat wrapper needs to do more checking
506816  futex2, futex_waitv WARNING: unhandled amd64-linux syscall: 449
506910  openat2 with RESOLVE_NO_MAGICLINKS succeeds on /proc/self/exe
506928  Wrap (deprecated) linux specific ustat syscall
506929  Wrap (deprecated) linux sysfs syscall
506930  valgrind allows SIGKILL being reset to SIG_DFL
506967  Implement and override mallinfo2
506970  mmap needs an EBADF fd_allowed check
507033  Remove deprecated Iop_Clz32/64 and Iop_Ctz32/64
507173  s390x: Crash when constant folding is disabled
507188  memcheck with track-fds=yes on x86 with popen: Assertion
507720  Review syscalls returning file descriptors (other platforms)
507721  Wire up illumos and Solaris mallinfo
507853  faccessat and faccessat2 should handle AT_FDCWD and absolute paths
507866  fanotify_mark dirfd isn't checked
507867  perf_event_open group_fd isn't checked
507868  futimesat doesn't handle AT_FDCWD
507869  Various at syscalls don't check dirfd argument
507873  Make fchmodat and fchmodat2 syscall wrappers accept AT_FDCWD
507897  Allow for patching LTP sources
507970  -Wcalloc-transposed-args warnings in valgrind-di-server.c
508027  Fix mips32 FTBFS
508029  Review the vmsplice syscall wrapper
508030  Add several missing syscall hooks to ppc64-linux
508093  VALGRIND_CLO_CHANGE does not update vex_control
508145  ppc64le needs ld.so hardwire for strcmp
508154  PRE(sys_fchownat) not handling VKI_AT_FDCWD
508638  Self-hosting not working on FreeBSD
508777  amd64-linux: add minimal scalar test
508778  syscall-wrapper waitid warns about infop=null
508779  PRE(sys_prlimit64): reorder check for memory validity
508869  x86-linux: simplify scalar test output
508958  FreeBSD: add getgroups and setgroups wrappers
509103  Fix tests/arm64/bug484935.c build with "-O2 -flto -ffat-lto-objects"
509107  memcheck/tests/duplicate_align_size_errors.cpp fails
509139  Update BadSize error messages
509258  FreeBSD: add jail_attach_jd and jail_remove_jd syscall wrappers
509406  FreeBSD 15 issues
509517  s390x: Even/odd lane confusion in various vector insns
509566  Wrap amd64-linux syscall: 442 (mount_setattr)
509572  s390x: Overhaul BFP testsuite
509590  Run the LTP tests with LTP_QUIET
509567  unhandled amd64-linux syscall: 443 (quotactl_fd)
509642  Add missing ppc64-linux syswraps
509643  Add missing s390x-linux syswraps
510169  Update the LTP version in valgrind testsuite to 20250930
510292  Silence false positive failure of LTP munmap01
510436  Don't warn about fcntl F_GETFD with --track-fds
510694  Handle qExecAndArgs remote protocol packet

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.26.0.RC1: 17 Oct 2025)

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

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

> On 24 Oct 2025, at 07:54, Paul Floyd via Valgrind-users <val...@li...> wrote:
> 
> 
>>> On 24 Oct 2025, at 02:18, Mark Wielaard <ma...@kl...> wrote:
>>> 
>>> 
>>> helgrind/tests/getaddrinfo               (stderr)
>> This one is "flaky" on some other arches too.
> 
> That means that suppressions should be added so that it passes. The testcase does not contain any errors. ‘getaddrinfo’ seems to use many libc non-pthread internal locks which are not recognised by Helgrind or DRD.
> 

… or existing suppressions wildcarded if they are “near misses”.

A+
Paul

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

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

> On 24 Oct 2025, at 02:18, Mark Wielaard <ma...@kl...> wrote:
> 
> 
>> helgrind/tests/getaddrinfo               (stderr)
> This one is "flaky" on some other arches too.

That means that suppressions should be added so that it passes. The testcase does not contain any errors. ‘getaddrinfo’ seems to use many libc non-pthread internal locks which are not recognised by Helgrind or DRD.

A+
Paul

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

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

Hi Abhay,

On Thu, Oct 23, 2025 at 04:10:23PM +0530, Abhay Kandpal wrote:
> I tested on ppcle 10 with GCC 14.3.1 and GLIBC 2.40
> Below are new failures observed.

Thanks.
 
> == 794 tests, 6 stderr failures, 0 stdout failures, 1 stderrB failure, 0 stdoutB failures, 0 post failures ==
> gdbserver_tests/mcleak                   (stderr)
> gdbserver_tests/mcleak                   (stderrB)
> memcheck/tests/leak-delta                (stderr)

If leak-delta fails, then the mcleak failures are probably the same.
What does memcheck/tests/leak-delta.stderr.diff say?

> memcheck/tests/linux/rfcomm              (stderr)

This seems a long standing issue, it looks like and endian issue?
It is for testing an bluetooth connection.

> helgrind/tests/getaddrinfo               (stderr)
This one is "flaky" on some other arches too.

> none/tests/fdleak_cmsg_xml               (stderr)
> none/tests/socket_close_xml              (stderr)
> 
> 
> Comparing with older release below are new two
> none/tests/fdleak_cmsg_xml               (stderr)
> none/tests/socket_close_xml              (stderr)
> 
> The above two failure are regular and non-critical in nature. Hence they are not blocker for this release.
> I tested on other power versions also and found similar result.
> 
> We will investigate the new regression after the release.

Thanks. I agree that these results seem non-critical.

It is a little surprising the xml variants fail, but apparently not
the non-xml output ones. I do note there is a special ppc64le
socket_close_xml.stderr.exp-ppc64le and
fdleak_cmsg_xml.stderr.exp-ppc64le expect files which are missing one
call frame. Maybe that is related?

Cheers,

Mark

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

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

On Sat, Oct 18, 2025 at 04:43:59AM +0200, Mark Wielaard wrote:
> An RC1 tarball for 3.26.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.26.0.RC1.tar.bz2
> (md5sum = b7798804b18476104073009043ecc96d)
> (sha1sum = bc1bffd272b3a14b3ba9c1cc5a25a5e3975b9c8a)
> https://sourceware.org/pub/valgrind/valgrind-3.26.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
> 
> The final 3.26.0 release is scheduled for Fri Oct 24.

The following are the test results on Fedora rawhide.

i686:

== 841 tests, 4 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/descr_belowsp             (stderr)
memcheck/tests/x86-linux/scalar          (stderr)
drd/tests/std_thread2                    (stderr)
none/tests/x86/lzcnt32                   (stdout)
none/tests/x86/lzcnt32                   (stderr)

x86_64:

== 853 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/descr_belowsp             (stderr)
helgrind/tests/tc22_exit_w_lock          (stderr)
drd/tests/std_thread2                    (stderr)

aarch64:

== 768 tests, 19 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 0 post failures ==
gdbserver_tests/hgtls                    (stdoutB)
memcheck/tests/arm64-linux/scalar        (stderr)
memcheck/tests/descr_belowsp             (stderr)
memcheck/tests/dw4                       (stderr)
memcheck/tests/fwrite                    (stderr)
memcheck/tests/linux/sys-copy_file_range (stderr)
memcheck/tests/linux/sys-preadv_pwritev  (stderr)
memcheck/tests/sendmsg                   (stderr)
memcheck/tests/varinfo2                  (stderr)
memcheck/tests/varinfo4                  (stderr)
memcheck/tests/varinfo5                  (stderr)
memcheck/tests/varinfo6                  (stderr)
memcheck/tests/varinforestrict           (stderr)
memcheck/tests/writev1                   (stderr)
helgrind/tests/hg05_race2                (stderr)
helgrind/tests/tc20_verifywrap           (stderr)
drd/tests/tls_threads                    (stderr)
none/tests/track_bad                     (stderr)
none/tests/track_new                     (stderr)
none/tests/use_after_close               (stderr)

ppc64le:

== 760 tests, 12 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/descr_belowsp             (stderr)
memcheck/tests/fwrite                    (stderr)
memcheck/tests/linux/sys-copy_file_range (stderr)
memcheck/tests/linux/sys-preadv_pwritev  (stderr)
memcheck/tests/sendmsg                   (stderr)
memcheck/tests/writev1                   (stderr)
helgrind/tests/getaddrinfo               (stderr)
none/tests/fdleak_cmsg_xml               (stderr)
none/tests/socket_close_xml              (stderr)
none/tests/track_bad                     (stderr)
none/tests/track_new                     (stderr)
none/tests/use_after_close               (stderr)

s390x:

== 892 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 4 post failures ==
memcheck/tests/descr_belowsp             (stderr)
helgrind/tests/tc22_exit_w_lock          (stderr)
drd/tests/bar_bad_xml                    (stderr)
none/tests/s390x/bfp-emit                (post)
none/tests/s390x/bfp-XxC                 (post)
none/tests/s390x/dfp-XiC                 (post)
none/tests/s390x/dfp-XxC                 (post)

The last 4 look like I messed up the install:
valgrind: failed to start tool 'none' for platform 's390x-linux': No such file or directory

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

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

Hi,

On Sat, Oct 18, 2025 at 04:43:59AM +0200, Mark Wielaard wrote:
> An RC1 tarball for 3.26.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.26.0.RC1.tar.bz2
> (md5sum = b7798804b18476104073009043ecc96d)
> (sha1sum = bc1bffd272b3a14b3ba9c1cc5a25a5e3975b9c8a)
> https://sourceware.org/pub/valgrind/valgrind-3.26.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
> 
> The final 3.26.0 release is scheduled for Fri Oct 24.

I updated the NEWS file with some more items. It was a busy release,
400 commits, 85 bug fixes. So I might have missed some things. Please
feel free to suggest or add something.

  - Upgrade to the GNU General Public License version 3.
  - Make BUILD_DOCS controls building documentation.
  - New VEX API function LibVEX_set_VexControl.
  - Deprecated IROps: Iop_Clz32/64 and Iop_Ctz32/64 have been removed.
  - LTP integration has been updated to v20250930.
  - New Linux syscall wrappers (cachestat, futex_waitv, listmount,
    mount_setattr, mseal, quotactl_fd, remap_file_pages, setdomainname,
    statmount, swapoff, swapon, sysfs and ustat).
  - New --modify-fds=yes is like --modify-fds=high except for fds 0,1,2.
  - New --track-fds=bad only produces errors for bad file descriptor usage.
  - With --xml=yes log now always uses output protocol 6.
  - vgdb now handles the qExecAndArgs packet.
  - DWARF inlined subroutine handling has been rewritten to work cross CUs.
  - Using vgdb on FreeBSD 15 needs sysctl debug.ptrace_attach_transparent=0.
  - There is a new utility script, vgstack.
  - Memcheck handling of aligned allocation with size of zero changed:
    - free_aligned_sized with a size of zero is no longer an error.
    - memalign, aligned_alloc and posix_memalign produce a different error
      "Unsafe allocation with size of zero is implementation-defined".
    - The suppression name has changed from "BadSize" to "UnsafeZeroSize".
  - Checks for C23 free_sized and free_aligned_sized have been added.

Full list: https://sourceware.org/cgit/valgrind/tree/NEWS

Cheers,

Mark

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

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

An RC1 tarball for 3.26.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.26.0.RC1.tar.bz2
(md5sum = b7798804b18476104073009043ecc96d)
(sha1sum = bc1bffd272b3a14b3ba9c1cc5a25a5e3975b9c8a)
https://sourceware.org/pub/valgrind/valgrind-3.26.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

The final 3.26.0 release is scheduled for Fri Oct 24.

[Valgrind-users] Git/master Valgrind + Qt Creator XML/socket logging crash

[Thomas W. <wol...@ms...>]

Hello,
I am currently using a Git/master build of Valgrind (3.26.0.GIT) on Ubuntu, and it works perfectly when run from the terminal using standard command-line options, e.g.:

valgrind --tool=memcheck ./MyApp


However, when I try to run the same executable via Qt Creator’s Valgrind integration, which launches Valgrind with the following options:

--child-silent-after-fork=yes
--xml-socket=127.0.0.1:<port>
--log-socket=127.0.0.1:<port>
--xml=yes
--smc-check=stack
--tool=memcheck
--gen-suppressions=all
--track-origins=yes
--leak-check=summary
--num-callers=25


Valgrind crashes immediately with:

valgrind: ../../coregrind/m_libcprint.c:402 (prepare_sink_socket): Assertion 'sink->fd == 2' failed.
Segmentation fault (core dumped)


>From my observations:

  *
The crash appears only when XML/socket logging is used.
  *
The runtime binaries (e.g., memcheck-amd64-linux and vgpreload_*.so) are present in the build directory, not in the lib/valgrind folder, but Valgrind works fine when called directly from the terminal.
  *
Using the Ubuntu system Valgrind package avoids the crash with Qt Creator.

My questions are:

  1.
Is this behavior a known issue with Git/master builds of Valgrind?
  2.
Are there plans to support Qt Creator’s XML/socket logging fully in future releases?
  3.
Are there recommended workarounds for using Git/master Valgrind with IDEs that rely on socket-based logging?

Thank you for any insights or guidance.
Best regards,
Thomas

Re: [Valgrind-users] Valgrind fails to perform

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

On 2025-08-27 01:49, Igor Korot wrote:
> Hi, ALL,
>
> My name is Igor and I'm a cross-platform developer.
>
> Recently my program started experiencing crashes, so I decided to try valgrind.


Hi

Please could you try the patch that is part of this bugzilla item

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

and let us know if it works?

The patch doesn't have a regression test which is probably why it hasn't 
made it into git.


A+

Paul

[Valgrind-users] Valgrind fails to perform

[Igor K. <iko...@gm...>]

Hi, ALL,

My name is Igor and I'm a cross-platform developer.

Recently my program started experiencing crashes, so I decided to try valgrind.

Here is the session:

[code]
igor@WaylandGnome ~/dbhandler/Debug/dbhandler $ valgrind
--leak-check=yes ./dbhandler
==16807== Memcheck, a memory error detector
==16807== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==16807== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==16807== Command: ./dbhandler
==16807==
vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0x78 0x10 0xD0
0x8 0x4 0x0 0x0 0x89
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==16807== valgrind: Unrecognised instruction at address 0x40149d7.
==16807==    at 0x40149D7: get_common_indices.constprop.0 (in
/lib64/ld-linux-x86-64.so.2)
==16807==    by 0x401604E: init_cpu_features.constprop.0 (in
/lib64/ld-linux-x86-64.so.2)
==16807==    by 0x4016360: _dl_x86_init_cpu_features (in
/lib64/ld-linux-x86-64.so.2)
==16807==    by 0x401974B: _dl_sysdep_start (in /lib64/ld-linux-x86-64.so.2)
==16807==    by 0x401AECD: _dl_start (in /lib64/ld-linux-x86-64.so.2)
==16807==    by 0x4019D17: ??? (in /lib64/ld-linux-x86-64.so.2)
==16807== Your program just tried to execute an instruction that Valgrind
==16807== did not recognise.  There are two possible reasons for this.
==16807== 1. Your program has a bug and erroneously jumped to a non-code
==16807==    location.  If you are running Memcheck and you just saw a
==16807==    warning about a bad jump, it's probably your program's fault.
==16807== 2. The instruction is legitimate but Valgrind doesn't handle it,
==16807==    i.e. it's Valgrind's fault.  If you think this is the case or
==16807==    you are not sure, please let us know and we'll try to fix it.
==16807== Either way, Valgrind will now raise a SIGILL signal which will
==16807== probably kill your program.
==16807==
==16807== Process terminating with default action of signal 4 (SIGILL)
==16807==  Illegal opcode at address 0x40149D7
==16807==    at 0x40149D7: get_common_indices.constprop.0 (in
/lib64/ld-linux-x86-64.so.2)
==16807==    by 0x401604E: init_cpu_features.constprop.0 (in
/lib64/ld-linux-x86-64.so.2)
==16807==    by 0x4016360: _dl_x86_init_cpu_features (in
/lib64/ld-linux-x86-64.so.2)
==16807==    by 0x401974B: _dl_sysdep_start (in /lib64/ld-linux-x86-64.so.2)
==16807==    by 0x401AECD: _dl_start (in /lib64/ld-linux-x86-64.so.2)
==16807==    by 0x4019D17: ??? (in /lib64/ld-linux-x86-64.so.2)
==16807==
==16807== HEAP SUMMARY:
==16807==     in use at exit: 0 bytes in 0 blocks
==16807==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==16807==
==16807== All heap blocks were freed -- no leaks are possible
==16807==
==16807== For lists of detected and suppressed errors, rerun with: -s
==16807== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction
[/code]

What is the problem?

I'm running Gentoo Linux.

Thank you.

[Valgrind-users] Compiling Valgrind with mips-linux-muslsf-gcc

[Yannik M. <yma...@me...>]

Hey all,

I am currently attempting to compile valgrind with 
mips-linux-muslsf-gcc, but it errors out because guest_mips_helpers.c 
uses floating point registers, which are not available in the softfloat 
target. Any help would be appreciated.

The steps below can be used to reproduce this:

1. wget https://musl.cc/mips-linux-muslsf-cross.tgz
2. tar -xzf mips-linux-muslsf-cross.tgz
3. export PATH=$PATH:$(pwd)/mips-linux-muslsf-cross/bin
4. git clone https://sourceware.org/git/valgrind.git
5. cd valgrind
6. ./autogen.sh
7. ./configure --host=mips-linux-muslsf
8. make

Below are the first few errors that I am seeing:

priv/guest_mips_helpers.c: In function 
‘mips_dirtyhelper_calculate_FCSR_fp32’:
priv/guest_mips_helpers.c:501:4: error: the register ‘$f21’ cannot be 
clobbered in ‘asm’ for the current target
   501 |    __asm__ volatile(".set  push"        "\n\t" 
     \
       |    ^~~~~~~
priv/guest_mips_helpers.c:644:10: note: in expansion of macro 
‘ASM_VOLATILE_UNARY32_DOUBLE’
   644 |          ASM_VOLATILE_UNARY32_DOUBLE(round.w.d)
       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
priv/guest_mips_helpers.c:486:4: error: the register ‘$f20’ cannot be 
clobbered in ‘asm’ for the current target
   486 |    __asm__ volatile(".set  push"        "\n\t" 
     \
       |    ^~~~~~~
priv/guest_mips_helpers.c:647:10: note: in expansion of macro 
‘ASM_VOLATILE_UNARY32’
   647 |          ASM_VOLATILE_UNARY32(floor.w.s)
       |

Best regards,
Yannik Marchand

Re: [Valgrind-users] Broken link

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

What book is that, and where did you see the link?

Tom

On 19/08/2025 14:22, Brian Salehi via Valgrind-users wrote:
> Hi,
> 
> I’ve just joined this list as I’m beginning to learn Valgrind for work. While browsing the website for the user manual, I noticed that the link to the Valgrind 3.3 book appears to be broken. If this is only a temporary issue on my side, please excuse the noise.
> 
> Since the book dates back quite a while, I’m also wondering whether it is still considered worth reading, or if it has become largely obsolete given newer releases of Valgrind. I’d appreciate any comments on this matter.
> 
> Best regards,
> Brian
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


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

Re: [Valgrind-users] Broken link

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

On 8/19/25 16:18, Brian Salehi via Valgrind-users wrote:
> Hey Tom, thanks for the reply.
> Here is the link to the page introducing the book:
>
> https://valgrind.org/docs/books.html
>
I'm not sure that is much use these days. It's about 17 years old and 
you'll only be able to get a secondhand copy.

Google gives me these sources 
https://www.google.fr/books/edition/Valgrind_3_3/h7EvNQAACAAJ?hl=en

We should fix the broken link/

A+

Paul

Re: [Valgrind-users] Broken link

[Brian S. <bri...@pr...>]

Hey Tom, thanks for the reply.
Here is the link to the page introducing the book: 

https://valgrind.org/docs/books.html

Bests,
Brian


-------- Original Message --------
On 8/19/25 16:14, Tom Hughes <to...@co...> wrote:

>  What book is that, and where did you see the link?
>  
>  Tom
>  
>  On 19/08/2025 14:22, Brian Salehi via Valgrind-users wrote:
>  > Hi,
>  >
>  > I’ve just joined this list as I’m beginning to learn Valgrind for work. While browsing the website for the user manual, I noticed that the link to the Valgrind 3.3 book appears to be broken. If this is only a temporary issue on my side, please excuse the noise.
>  >
>  > Since the book dates back quite a while, I’m also wondering whether it is still considered worth reading, or if it has become largely obsolete given newer releases of Valgrind. I’d appreciate any comments on this matter.
>  >
>  > Best regards,
>  > Brian
>  >
>  >
>  > _______________________________________________
>  > Valgrind-users mailing list
>  > Val...@li...
>  > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>  
>  
>  --
>  Tom Hughes (to...@co...)
>  http://compton.nu/
>  

[Valgrind-users] Broken link

[Brian S. <bri...@pr...>]

Hi,

I’ve just joined this list as I’m beginning to learn Valgrind for work. While browsing the website for the user manual, I noticed that the link to the Valgrind 3.3 book appears to be broken. If this is only a temporary issue on my side, please excuse the noise.

Since the book dates back quite a while, I’m also wondering whether it is still considered worth reading, or if it has become largely obsolete given newer releases of Valgrind. I’d appreciate any comments on this matter.

Best regards,
Brian

Re: [Valgrind-users] a simple case of a helgrind false negative?

[David F. <fa...@kd...>]

On Monday, 4 August 2025 16:24:38 David Yonge-Mallo wrote:
> Running helgrind naturally produces the output that there is a data race in
> "flag" between the two threads.
> 
> If the flag is replaced by an atomic, helgrind produces a clean report.

Yes, thait seems correct to me.

> According to my understanding, this is a false negative. There is still no
> "happens-before" relationship between the read in thread #1 and the write
> in thread #2. The program can terminate with copyOfFlag being either true
> or false, which means the race condition still exists.

Well, using an atomic turns the data race into what I would call a "semantic" 
race (if anyone knows the official term for this, I'm interested). There are 
many things you can do in a multithreaded program which follows the rules of 
the C/C++ memory model (such as using an atomic in this case) and which still 
leads to semantic races. This is one of them.

> According to my colleague, helgrind by design only cares that a read and a
> write on the same memory does not happen at the same time, and making the
> bool atomic fixes this.

It's not really about "at the same time", it could be much later, but as long 
as there's no synchronization mechanism between the two things, it's a data 
race.
(Think of an ARM CPU with two cores, each with their own cache, the caches 
aren't necessarily synchronized so you can be reading the wrong value forever 
even "after" a write, if the read happens on the other core and nothing syncs 
the caches).

> The indeterminacy of the value of copyOfFlag is a
> separate issue, which helgrind cannot detect as it is not within the scope
> of its design.

That's right.

> I claimed that helgrind does not understand atomic variables. My colleague
> disbelieved this and made the counterargument that if a mutex is used to
> guard access to flag (instead of making it atomic), it also produces a
> clean report, and since helgrind undoubtedly understands mutexes, it must
> mean that the data race is fixed.

Yes, the "data race" (as defined by the C/C++ memory model) is technically 
fixed, even though a "semantic" race is still happening.

Imagine a program where one thread increments an atomic int repeatedly and 
another thread decrements an atomic int repeatedly. Or an int protected by a 
mutex, same thing. It's all perfectly legal from the C/C++ standards' point of 
view, there's no data race that leads to undefined behaviour at the compiler/
CPU level. And yet the whole idea of such a program leads to indeterminism, 
you have no idea what the int's value will be after 10 seconds, because it all 
depends on thread scheduling by the OS.

There are many more factors for indeterminism than data races ;-)

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr

[Valgrind-users] a simple case of a helgrind false negative?

[David Yonge-M. <dav...@gm...>]

Hi, everyone,

I would like some help from helgrind experts to settle a disagreement with
a colleague.

We have the following code (very simplified):

--- begin example.cpp ---
#include <pthread.h>
#include <iostream>
#include <atomic>

bool flag = false;  // std::atomic<bool> flag{false};

void* callbackEvent(void* whatever) {
    flag = true;
    return whatever;
}

int main(void) {
    pthread_t callback_thread;

    pthread_create(&callback_thread, NULL, callbackEvent, NULL);

    bool copyOfFlag = flag;
    if (!copyOfFlag) {
        std::cout << "value of flag: " << copyOfFlag << std::endl;  // do
stuff assuming flag is false
    }

    pthread_join(callback_thread, NULL);
}
--- end example.cpp ---

> g++ -lpthread example.cpp -o example && valgrind --tool=helgrind
./example

Running helgrind naturally produces the output that there is a data race in
"flag" between the two threads.

If the flag is replaced by an atomic, helgrind produces a clean report.

According to my understanding, this is a false negative. There is still no
"happens-before" relationship between the read in thread #1 and the write
in thread #2. The program can terminate with copyOfFlag being either true
or false, which means the race condition still exists.

According to my colleague, helgrind by design only cares that a read and a
write on the same memory does not happen at the same time, and making the
bool atomic fixes this. The indeterminacy of the value of copyOfFlag is a
separate issue, which helgrind cannot detect as it is not within the scope
of its design.

I claimed that helgrind does not understand atomic variables. My colleague
disbelieved this and made the counterargument that if a mutex is used to
guard access to flag (instead of making it atomic), it also produces a
clean report, and since helgrind undoubtedly understands mutexes, it must
mean that the data race is fixed.

What is the correct view here?

Thank you for your time.

p.s. I am aware of bug 339330, but technically it only mentions false
positives and this is a case of (what I believe to be) a false negative.

-- 
David Yonge-Mallo

[Valgrind-users] Valgrind-3.25.1 is available

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

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

This point release contains only bug fixes.

See the list of bugs and the git shortlog below for details of the changes.

Happy and productive debugging and profiling,

-- The Valgrind Developers

Release 3.25.1 (20 May 2025)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This point release contains only bug fixes.

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

The following bugs have been fixed or resolved in this point release.

503098  Incorrect NAN-boxing for float registers in RISC-V
503641  close_range syscalls started failing with 3.25.0
503914  mount syscall param filesystemtype may be NULL
504177  FILE DESCRIPTORS banner shows when closing some inherited fds
504265  FreeBSD: missing syscall wrappers for fchroot and setcred
504466  Double close causes SEGV

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.

git shortlog
~~~~~~~~~~~~

Ivan Tetyushkin (1):
  riscv64: Fix nan-boxing for single-precision calculations

Mark Wielaard (9):
  Set version to 3.25.1.GIT
  Prepare NEWS for branch 3.25 fixes
  mount syscall param filesystemtype may be NULL
  Add workaround for missing riscv_hwprobe syscall (258)
  Don't count closed inherited file descriptors
  More gdb filtering for glibc 2.41 with debuginfo installed
  Check whether file descriptor is inherited before printing where_opened
  Add fixed bug 504466 double close causes SEGV to NEWS
  -> 3.25.1 final

Paul Floyd (6):
  FreeBSD close_range syscall
  Bug 503641 - close_range syscalls started failing with 3.25.0
  regtest: use /bin/cat in none/tests/fdleak_cat.vgtest
  Linux PPC64 syscall: add sys_io_pgetevents
  Bug 504265 - FreeBSD: missing syscall wrappers for fchroot and setcred
  FreeBSD regtest: updates for FreeBSD 15.0-CURRENT

[Valgrind-users] Valgrind-3.25.0 is available

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

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

This release adds initial support for RISCV64/Linux, the GDB remote
packet 'x', zstd compressed debug sections, Linux Test Project
testsuite integration, numerous fixes for Illumos, FreeBSD atexit
filters and getrlimitusage syscall support, Linux syscall support for
landlock*, io_pgetevents, open_tree, move_mount, fsopen, fsconfig,
fsmount, fspick, userfaultfd, s390x BPP, BPRP, PPA and NIAI instruction
support, --track-fds=yes improvements and a new --modify-fds=high
option, and an helgrind --check-cond-signal-mutex=yes|no option.

See the release notes below for details of the 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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Release 3.25.0 (25 Apr 2025)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

* The valgrind gdbserver now supports the GDB remote protocol packet
  'x addr,len' (available in GDB release >= 16).
  The x packet can reduce the time taken by GDB to read memory from valgrind.

* Valgrind now supports zstd compressed debug sections.

* The Linux Test Project (ltp) is integrated in the testsuite try
  'make ltpchecks' (this will take a while and will point out various
  missing syscalls and valgrind crashes!)

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

* Added RISCV64 support for Linux. Specifically for the RV64GC
  instruction set.

* Numerous bug fixes for Illumos, in particular fixed a Valgrind crash
  whenever a signal handler was called.

* On FreeBSD, a change to the libc code that runs atexit handlers was
  causing Helgrind to produce an extra error about exiting threads
  still holding locks for. This applied to every multithreaded application.
  The extra error is now filtered out. A syscall wrapper had been added
  for getrlimitusage.

* On Linux various new syscalls are supported (landlock*, io_pgetevents,
  open_tree, move_mount, fsopen, fsconfig, fsmount, fspick, userfaultfd).

* s390x has support for various new instructions (BPP, BPRP, PPA and NIAI).

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

* The --track-fds=yes and --track-fds=all options now treat all
  inherited file descriptors the same as 0, 1, 2 (stdin/out/err).
  And when the stdin/out/err descriptors are reassigned they are
  now treated as normal (non-inherited) file descriptors.

* A new option --modify-fds=high can be used together with
  --track-fds=yes to create new file descriptors with the highest
  possible number (and then decreasing) instead of always using the
  lowest possible number (which is required by POSIX). This will help
  catch issues where a file descriptor number might normally be reused
  between a close and another open call.

* Helgrind:
  There is a change to warnings about calls to pthread_cond_signal and
  pthread_cond_broadcast when the associated mutex is unlocked. Previously
  Helgrind would always warn about this. Now this error is controlled by
  a command line option, --check-cond-signal-mutex=yes|no. The default is
  no. This change has been made because some C and C++ standard libraries
  use pthread_cond_signal/pthread_cond_broadcast in this way. Users are
  obliged to use suppressions if they wish to avoid this noise.

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

290061  pie elf always loaded at 0x108000
396415  Valgrind is not looking up $ORIGIN rpath of shebang programs
420682  io_pgetevents is not supported
468575  Add support for RISC-V
469782  Valgrind does not support zstd-compressed debug sections
487296  --track-fds=yes and --track-fds=all report erroneous information
        when fds 0, 1, or 2 are used as non-std
489913  WARNING: unhandled amd64-linux syscall: 444 (landlock_create_ruleset)
493433  Add --modify-fds=[no|high] option
494246  syscall fsopen not wrapped
494327  Crash when running Helgrind built with #define TRACE_PTH_FNS 1
494337  All threaded applications cause still holding lock errors
495488  Add FreeBSD getrlimitusage syscall wrapper
495816  s390x: Fix disassembler segfault for C[G]RT and CL[G]RT
495817  s390x: Disassembly to match objdump -d output
496370  Illumos: signal handling is broken
496571  False positive for null key passed to bpf_map_get_next_key syscall.
496950  s390x: Fix hardware capabilities and EmFail codes
497130  Recognize new DWARF5 DW_LANG constants
497455  Update drd/scripts/download-and-build-gcc
497723  Enabling Ada demangling breaks callgrind differentiation between
        overloaded functions and procedures
498037  s390x: Add disassembly checker
498143  False positive on EVIOCGRAB ioctl
498317  FdBadUse is not a valid CoreError type in a suppression
        even though it's generated by --gen-suppressions=yes
498421  s390x: support BPP, BPRP and NIAI insns
498422  s390x: Fix VLRL and VSTRL insns
498492  none/tests/amd64/lzcnt64 crashes on FreeBSD compiled with clang
498629  s390x: Fix S[L]HHHR and S[L]HHLR insns
498632  s390x: Fix LNGFR insn
498942  s390x: Rework s390_disasm interface
499183  FreeBSD: differences in avx-vmovq output
499212  mmap() with MAP_ALIGNED() returns unaligned pointer
501119  memcheck/tests/pointer-trace fails when run on NFS filesystem
501194  Fix ML_(check_macho_and_get_rw_loads) so that it is correct for
        any number of segment commands
501348  glibc built with -march=x86-64-v3 does not work due to ld.so memcmp
501479  Illumos DRD pthread_mutex_init wrapper errors
501365  syscall userfaultfd not wrapped
501846  Add x86 Linux shm wrappers
501850  FreeBSD syscall arguments 7 and 8 incorrect.
501893  Missing suppression for __wcscat_avx2 (strcat-strlen-avx2.h.S:68)?
502126  glibc 2.41 extra syscall_cancel frames
502288  s390x: Memcheck false positives with NNPA last tensor dimension
502324  s390x: Memcheck false positives with TMxx and TM/TMY
502679  Use LTP for testing valgrind
502871  Make Helgrind "pthread_cond_{signal,broadcast}: dubious: associated
        lock is not held by any thread" optional

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.25.0.RC1: 18 Apr 2025)
(3.25.0.RC2: 23 Apr 2025)

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

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

Hi Jeevitha,

On Fri, 2025-04-25 at 13:15 +0000, P Jeevitha wrote:
> Hi Everyone,
> valgrind-3.25.0.RC2 also looks good on Power and that there are no issues requiring fixes before releasing .

Thanks again. I have just tagged the final 3.25.0 release in git. Will
update the website and then announce the release officially.

Cheers,

Mark

> The PowerPC testsults for Both LE & BE are as follows
> 
> Powerpc64LE Results:
> 
> Power8:
> There are no new failures compared to valgrind-3.25.0.RC1. 
>  
> == 768 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 3 post failures ==
> memcheck/tests/leak_cpp_interior         (stderr)
> memcheck/tests/linux/rfcomm              (stderr)
> memcheck/tests/linux/sys-execveat        (stderr)
> massif/tests/bug469146                   (post)
> massif/tests/new-cpp                     (post)
> massif/tests/overloaded-new              (post)
>  
>  
> Power9:
> There are no new failures compared to valgrind-3.25.0.RC1.
>  
> == 775 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
> memcheck/tests/linux/rfcomm              (stderr)
>  
>  
> Power10:
> There are no new failures compared to valgrind-3.25.0.RC1.
>  
> == 781 tests, 7 stderr failures, 2 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
> memcheck/tests/execve1                   (stderr)
> memcheck/tests/execve2                   (stderr)
> memcheck/tests/linux/rfcomm              (stderr)
> memcheck/tests/thread_alloca             (stderr)
> helgrind/tests/getaddrinfo               (stderr)
> drd/tests/getaddrinfo                    (stderr)
> none/tests/allexec32                     (stdout)
> none/tests/allexec64                     (stdout)
> none/tests/scripts/shell                 (stderr)
>  
>  
> PowerpcBE Results:
>  
> Power8:
> There are no new failures compared to valgrind-3.25.0.RC1.
>  
> == 785 tests, 333 stderr failures, 70 stdout failures, 3 stderrB failures, 3 stdoutB failures, 6 post failures ==
>  
> Power9:
> There are no new failures compared to valgrind-3.25.0.RC1
>  
> == 819 tests, 52 stderr failures, 45 stdout failures, 1 stderrB failure, 2 stdoutB failures, 2 post failures ==
>  
> Thanks,
> Jeevitha           
>  
>  
> 
> 
> 
> 
> 
> 
> 
> 
> From:Mark Wielaard <ma...@kl...>
> Date: Thursday, 24 April 2025 at 7:31 AM
> To: val...@li... <val...@li...>, val...@li... <val...@li...>
> Subject: [EXTERNAL] [Valgrind-developers] Valgrind-3.25.0.RC2 is available for testing
> 
> 
> An RC2 tarball for 3.25.0 is now available at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_pub_valgrind_valgrind-2D3.25.0.RC2.tar.bz2&d=DwICAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=1GmuiRN2MNmsR6U1MCgzJDTJN341hwlj76xKBOp0NuQ&m=85bKzMP6w6T9IXjGhZvfahYOFbOzyF5743I9agGtperF27vw7g4Z4IMrGsRTwT00&s=_zaWTSpIMqnpXXiToInHiY_Kj1oYB8-M_2r5bfwdxIc&e=
> 
> (md5sum = 4e53a0a1a8d1404e77e6c45015eeb472)
> (sha1sum = ba482eeeb89dd271006f59b09f01048be6530a53)
> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_pub_valgrind_valgrind-2D3.25.0.RC2.tar.bz2.asc&d=DwICAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=1GmuiRN2MNmsR6U1MCgzJDTJN341hwlj76xKBOp0NuQ&m=85bKzMP6w6T9IXjGhZvfahYOFbOzyF5743I9agGtperF27vw7g4Z4IMrGsRTwT00&s=icWh0hJCWXeHglX3_TMvNDSHAHhLrk33SZCpK6IGtT8&e=
> 
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.kde.org_enter-5Fbug.cgi-3Fproduct-3Dvalgrind&d=DwICAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=1GmuiRN2MNmsR6U1MCgzJDTJN341hwlj76xKBOp0NuQ&m=85bKzMP6w6T9IXjGhZvfahYOFbOzyF5743I9agGtperF27vw7g4Z4IMrGsRTwT00&s=MhvwPxwO5oPkG89lLuOAA7ioFG7rG3VGQ5XMuPKRfL8&e=
> 
> 
> Changes from RC1:
> 
> Florian Krohm (2):
>   s390x: Fix a comment
>   s390x only: Clean up unused Ijk_... values
> 
> Mark Wielaard (4):
>   auxprogs/Makefile.am (EXTRA_DIST): Add ltpchecks helper files
>   Update NEWS for RISCV64/Linux and --modify-fds=[no|high] option
>   none/tests/riscv64/testinst.h: Use lla instead of la in JMP_RANGE
>   Set version to 3.25.0-RC2
> 
> Paul Floyd (8):
>   Bug 502871 - Make Helgrind "pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread" optional
>   Add 3.25 highlights to NEWS for FreeBSD.
>   Doc: add description of cond signal without mutex lock.
>   Helgrind regtest: use --check-cond-signal-mutex=yes in tc20_verifywrap
>   FreeBSD regtest: add auxv_script to dist_noinst_SCRIPTS
>   Illumos suppression and regtest
>   Illumos regtest: add an expected for none/tests/fdleak_socketpair_xml.stderr
>   Regtest: clean up warning and compilation of bug290061.c
> 
> Petr Pavlu (4):
>   riscv64: Fix tests compilation with newer GNU as
>   riscv64: Merge decoding of csrrw and csrrs
>   riscv64: Add support for csrrc
>   riscv64: Drop the not-needed type for FpCSEL
> 
> zhaomingxin (1):
>   riscv64: Add missing floating-point ITE/CSEL support in VEX backend
> 
> Unless a showstopper bug pops up 3.25.0 final will be released on
> Fri Apr 27.
> 
> 
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_valgrind-2Ddevelopers&d=DwICAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=1GmuiRN2MNmsR6U1MCgzJDTJN341hwlj76xKBOp0NuQ&m=85bKzMP6w6T9IXjGhZvfahYOFbOzyF5743I9agGtperF27vw7g4Z4IMrGsRTwT00&s=b7F7UfNVIc0UuSe0A8ffN7yQj0axX8xNn1R2SSgEE3I&e=

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

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

Hi Jeevitha,

On Fri, 2025-04-25 at 11:52 +0000, P Jeevitha wrote:
> Hi Everyone,
> 
> valgrind-3.25.0.RC1 looks good on Power and that there are no issues requiring fixes before releasing  Valgrind 3.25

Thanks so much for testing. The results do indeed look good. I am going
to prepare the 3.25.0 final release now.

I didn't see your message on the list, I am not sure why not. Maybe
because you are not subscribed, or because the message used HTML?

So I'll quote it in full below just to make sure others are aware of
your testing efforts.

Thanks,

Mark

> The PowerPC testsults for Both LE & BE are as follows
> 
> Powerpc64LE Results:
> 
> Power8:
> 
> There are no new failures compared to Valgrind 3.24.0.
> 
>  
> 
> == 768 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 3 post failures ==
> 
> memcheck/tests/leak_cpp_interior         (stderr)
> 
> memcheck/tests/linux/rfcomm              (stderr)
> 
> memcheck/tests/linux/sys-execveat        (stderr)
> 
> massif/tests/bug469146                   (post)
> 
> massif/tests/new-cpp                     (post)
> 
> massif/tests/overloaded-new              (post)
> 
>  
> 
>  
> 
> Power9:
> 
> There are no new failures compared to Valgrind 3.24.0.
> 
>  
> 
> == 775 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
> 
> memcheck/tests/linux/rfcomm              (stderr)
> 
>  
> 
>  
> 
> Power10:
> 
> There are no new failures compared to Valgrind 3.24.0.
> 
>  
> 
> == 781 tests, 7 stderr failures, 2 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
> 
> memcheck/tests/execve1                   (stderr)
> 
> memcheck/tests/execve2                   (stderr)
> 
> memcheck/tests/linux/rfcomm              (stderr)
> 
> memcheck/tests/thread_alloca             (stderr)
> 
> helgrind/tests/getaddrinfo               (stderr)
> 
> drd/tests/getaddrinfo                    (stderr)
> 
> none/tests/allexec32                     (stdout)
> 
> none/tests/allexec64                     (stdout)
> 
> none/tests/scripts/shell                 (stderr)
> 
>  
> 
>  
> 
>  
> 
>  
> 
> PowerpcBE Results:
> 
>  
> 
> Power8:
> 
> There are 2 new stderr failures and 1 new stdout failure compared to Valgrind 3.24.0, as these are newly added tests.  However these can be safely ignored as they were not reproduced on Power9.
> 
> Apart from previous expected failures from baseline , below are the additional failures.
> 
>  
> 
> == 785 tests, 333 stderr failures, 70 stdout failures, 3 stderrB failures, 3 stdoutB failures, 6 post failures ==
> 
>  
> 
> memcheck/tests/cdebug_zstd               (stderr)
> 
> memcheck/tests/wcscat                    (stdout)
> 
> memcheck/tests/wcscat                    (stderr)
> 
>  
> 
>  
> 
> Note: These test cases are failing due to missing symbols from certain packages. However, the issue is not reproducible on Power9.
> 
>  
> 
> Power9:
> 
> There are no new failures compared to Valgrind 3.24.0.
> 
>  
> 
> == 819 tests, 52 stderr failures, 45 stdout failures, 1 stderrB failure, 2 stdoutB failures, 2 post failures ==
> 
>  
> 
> Thanks,
> 
> Jeevitha           
> 
>  
>  
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------------------------------------------
> Subject:         [Valgrind-developers] Valgrind-3.25.0.RC1 is available for 
> testing
> Date:    Fri, 18 Apr 2025 15:53:59 +0200
> From:    Mark Wielaard <ma...@kl...>
> To:      val...@li..., 
> val...@li...
> 
> 
> 
> Slightly later than originally planned, but the RC1 is finally out!
> 
> An RC1 tarball for 3.25.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC1.tar.bz2
> (md5sum = 2f02fe951278ebde62bba65c3a311a40)
> (sha1sum = 3679ddc3237455f07de0ae30f21e947868c2218e)
> https://sourceware.org/pub/valgrind/valgrind-3.25.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
> 
> The NEWS file isn't complete up to date yet, but some highlights:
> 
> - Initial RISCV64/Linux support.
> - Valgrind gdbserver supports 'x' packets.
> - Numerous bug fixes for Illumos.
> - --track-fds=yes now treats all inherited file descriptors like
> stdin/out/err (0,1,2) and there is a --modify-fds=high option.
> - s390x support for various new instructions (BPP, BPRP and NIAI)
> - Various new linux syscalls are supported (landlock*, open_tree,
> move_mount, fsopen, fsconfig, fsmount, fspick, userfaultfd)
> - The Linux Test Project (ltp) is integrated in the testsuite
> try 'make ltpchecks' (this will take a while and will point out
> various missing syscalls and valgrind crashes!)
> 
> Since this RC1 is slightly later than planned and it is a long Easter
> weekend for those that celebrate, lets do the RC2 on Wed Apr 25, with
> the 3.25.0 final on Fri Apr 27.
> 
> 
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

Yes, VALGRIND_MAKE_MEM_DEFINED is the correct solution.
Philippe

On Fri, 2025-04-25 at 03:27 +0530, kiran hardas wrote:
> Hi Team,
> 
> Thanks Philippe for your response. I have now used these
> macros VALGRIND_MAKE_MEM_DEFINED after wherever i am attaching to the shared memory to
> mark it valid from valgrind perspective. These shared memory locations are anyway
> memsetted to 0 as part of initialisations once created. With this i don't see further
> invalid read errors. Is this fix/macro use fine?  
> 
> Thanks & Regards,
> Kiran H. 
> 
> On Wed, Apr 23, 2025 at 2:09 AM Philippe Waroquiers <phi...@sk...>
> wrote:
> > If you use some piece of shared memory in a process X and this piece of shared memory
> > is
> > initialized by another process Y, valgrind/X has no way to know that process Y has
> > initialized this memory.
> > 
> > The typical solution is to have process X marking the memory as initialized just
> > after it has attached to it.
> > 
> > Thanks
> > Philippe
> > 
> > On Wed, 2025-04-23 at 01:24 +0530, kiran hardas wrote:
> > > Hi Team,
> > > 
> > > Thanks John Reiser for your observations. In continuation of further valgrind
> > > testing, i
> > > am seeing below type of errors from my application code many times (around 200-300
> > > times).
> > > 
> > > ==3534== Invalid write of size 4
> > > ==3534==    at 0xF5FAD71: <application backtrace>
> > > ==3534==    by 0xF5FAD71:  <application backtrace>
> > > ==3534==    by 0xF1F073F:  <application backtrace>
> > > ==3534==  Address 0xf7fb1ce4 is not stack'd, malloc'd or (recently) free'd
> > > 
> > > 
> > > The line nos. pointed by these errors are places in code where i am using structure
> > > pointer variables to access structure members. This structure data is present in
> > > shared
> > > memory location. On printing the structure member values using pointers in debug
> > > logs, i
> > > dont see any problem with value.
> > > 
> > > My suspicion is that since we are skipping address advisory logic in valgrind
> > > wrapper
> > > during shmat attach call (passed with shmaddr as NULL), it is attaching to different
> > > memory location provided by kernel which the valgrind may be detecting as invalid.
> > > There
> > > are many similar errors coming from different parts of application code but relating
> > > to
> > > the same action of structure member access from shared memory.
> > > 
> > > One approach i was thinking is to suppress these invalid read errors using
> > > suppression
> > > option of valgrind because i dont see any related symptom of this error, as in no
> > > crash
> > > observed (seg fault). Will it be a proper approach? Would appreciate any
> > > sugestions/advice for this issue. Or should i need to check any particular code area
> > > or
> > > approach? Please do advice as it would be helpful. Thanks in advance!
> > > 
> > > 
> > > Thanks & Regards,
> > > Kiran H. 
> > > 
> > > On Tue, Apr 15, 2025 at 1:35 AM John Reiser <jr...@bi...> wrote:
> > > > On 4/14/25 7:13 AM, kiran hardas wrote:
> > > > > Hi Team,
> > > > > 
> > > > > I haven't received any suggestion or advice to my shmat valgrind wrapper 
> > > > > behaviour mentioned in previous mail.
> > > > 
> > > > > --- a/valgrind/coregrind/m_syswrap/syswrap-generic.c
> > > > > +++ b/valgrind/coregrind/m_syswrap/syswrap-generic.c
> > > > > @@ -2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid,
> > > > >    {
> > > > >       /* void *shmat(int shmid, const void *shmaddr, int shmflg); */
> > > > >       SizeT  segmentSize = get_shm_size ( arg0 );
> > > > > -   UWord tmp;
> > > > > +   UWord tmp = 0;
> > > > >       Bool  ok;
> > > > >       if (arg1 == 0) {
> > > > >          /* arm-linux only: work around the fact that
> > > > 
> > > > In the current git source for 
> > > > valgrind/coregrind/m_syswrap/syswrap-generic.c at function 
> > > > ML_(generic_PRE_sys_shmat) (line 2346), I see
> > > > =====
> > > >     if (arg1 == 0) {
> > > >        /* arm-linux only: work around the fact that
> > > >           VG_(am_get_advisory_client_simple) produces something that is
> > > >           VKI_PAGE_SIZE aligned, whereas what we want is something
> > > >           VKI_SHMLBA aligned, and VKI_SHMLBA >= VKI_PAGE_SIZE.  Hence
> > > >           increase the request size by VKI_SHMLBA - VKI_PAGE_SIZE and
> > > >           then round the result up to the next VKI_SHMLBA boundary.
> > > >           See bug 222545 comment 15.  So far, arm-linux is the only
> > > >           platform where this is known to be necessary. */
> > > > =====
> > > > where "git blame" for the first two lines says
> > > > =====
> > > > cc8ccbbfb4 coregrind/m_syswrap/syswrap-generic.c   (Julian Seward 
> > > > 2005-09-27 19:20:21 +0000 2346)    if (arg1 == 0) {
> > > > 566a25cf7e coregrind/m_syswrap/syswrap-generic.c   (Julian Seward 
> > > > 2010-10-06 15:24:39 +0000 2347)       /* arm-linux only: work around the 
> > > > fact that
> > > > =====
> > > > but I do not see any guard that tests for arm-linux only.  So I would
> > > > say that the current source has a bug!
> > > > 
> > > > Thus your change
> > > > > With this change, my shmat functions calls are working fine as different
> > > > > adresses
> > > > > are picked up for attach.
> > > > 
> > > > is not only OK; it should be propagated into the official source.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Valgrind-users mailing list
> > > > Val...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > 

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Team,

Thanks Philippe for your response. I have now used these
macros VALGRIND_MAKE_MEM_DEFINED after wherever i am attaching to the
shared memory to mark it valid from valgrind perspective. These shared
memory locations are anyway memsetted to 0 as part of initialisations once
created. With this i don't see further invalid read errors. Is this
fix/macro use fine?

Thanks & Regards,
Kiran H.

On Wed, Apr 23, 2025 at 2:09 AM Philippe Waroquiers <
phi...@sk...> wrote:

> If you use some piece of shared memory in a process X and this piece of
> shared memory is
> initialized by another process Y, valgrind/X has no way to know that
> process Y has
> initialized this memory.
>
> The typical solution is to have process X marking the memory as
> initialized just
> after it has attached to it.
>
> Thanks
> Philippe
>
> On Wed, 2025-04-23 at 01:24 +0530, kiran hardas wrote:
> > Hi Team,
> >
> > Thanks John Reiser for your observations. In continuation of further
> valgrind testing, i
> > am seeing below type of errors from my application code many times
> (around 200-300
> > times).
> >
> > ==3534== Invalid write of size 4
> > ==3534==    at 0xF5FAD71: <application backtrace>
> > ==3534==    by 0xF5FAD71:  <application backtrace>
> > ==3534==    by 0xF1F073F:  <application backtrace>
> > ==3534==  Address 0xf7fb1ce4 is not stack'd, malloc'd or (recently)
> free'd
> >
> >
> > The line nos. pointed by these errors are places in code where i am
> using structure
> > pointer variables to access structure members. This structure data is
> present in shared
> > memory location. On printing the structure member values using pointers
> in debug logs, i
> > dont see any problem with value.
> >
> > My suspicion is that since we are skipping address advisory logic in
> valgrind wrapper
> > during shmat attach call (passed with shmaddr as NULL), it is attaching
> to different
> > memory location provided by kernel which the valgrind may be detecting
> as invalid. There
> > are many similar errors coming from different parts of application code
> but relating to
> > the same action of structure member access from shared memory.
> >
> > One approach i was thinking is to suppress these invalid read errors
> using suppression
> > option of valgrind because i dont see any related symptom of this error,
> as in no crash
> > observed (seg fault). Will it be a proper approach? Would appreciate any
> > sugestions/advice for this issue. Or should i need to check any
> particular code area or
> > approach? Please do advice as it would be helpful. Thanks in advance!
> >
> >
> > Thanks & Regards,
> > Kiran H.
> >
> > On Tue, Apr 15, 2025 at 1:35 AM John Reiser <jr...@bi...>
> wrote:
> > > On 4/14/25 7:13 AM, kiran hardas wrote:
> > > > Hi Team,
> > > >
> > > > I haven't received any suggestion or advice to my shmat valgrind
> wrapper
> > > > behaviour mentioned in previous mail.
> > >
> > > > --- a/valgrind/coregrind/m_syswrap/syswrap-generic.c
> > > > +++ b/valgrind/coregrind/m_syswrap/syswrap-generic.c
> > > > @@ -2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid,
> > > >    {
> > > >       /* void *shmat(int shmid, const void *shmaddr, int shmflg); */
> > > >       SizeT  segmentSize = get_shm_size ( arg0 );
> > > > -   UWord tmp;
> > > > +   UWord tmp = 0;
> > > >       Bool  ok;
> > > >       if (arg1 == 0) {
> > > >          /* arm-linux only: work around the fact that
> > >
> > > In the current git source for
> > > valgrind/coregrind/m_syswrap/syswrap-generic.c at function
> > > ML_(generic_PRE_sys_shmat) (line 2346), I see
> > > =====
> > >     if (arg1 == 0) {
> > >        /* arm-linux only: work around the fact that
> > >           VG_(am_get_advisory_client_simple) produces something that is
> > >           VKI_PAGE_SIZE aligned, whereas what we want is something
> > >           VKI_SHMLBA aligned, and VKI_SHMLBA >= VKI_PAGE_SIZE.  Hence
> > >           increase the request size by VKI_SHMLBA - VKI_PAGE_SIZE and
> > >           then round the result up to the next VKI_SHMLBA boundary.
> > >           See bug 222545 comment 15.  So far, arm-linux is the only
> > >           platform where this is known to be necessary. */
> > > =====
> > > where "git blame" for the first two lines says
> > > =====
> > > cc8ccbbfb4 coregrind/m_syswrap/syswrap-generic.c   (Julian Seward
> > > 2005-09-27 19:20:21 +0000 2346)    if (arg1 == 0) {
> > > 566a25cf7e coregrind/m_syswrap/syswrap-generic.c   (Julian Seward
> > > 2010-10-06 15:24:39 +0000 2347)       /* arm-linux only: work around
> the
> > > fact that
> > > =====
> > > but I do not see any guard that tests for arm-linux only.  So I would
> > > say that the current source has a bug!
> > >
> > > Thus your change
> > > > With this change, my shmat functions calls are working fine as
> different adresses
> > > > are picked up for attach.
> > >
> > > is not only OK; it should be propagated into the official source.
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>

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

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

Hi,

On Thu, Apr 24, 2025 at 03:59:21AM +0200, Mark Wielaard wrote:
> 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

Some results from the buildbot, most look fairly good, except for the
armhf one, which has lots of regtest failures.

Debian GNU/Linux 12 (bookworm) Linux 6.1.0-32-686-pae #1 SMP
PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) GNU C Library (Debian
GLIBC 2.36-9+deb12u10) stable release version 2.36. g++ 12.2.0 GNU
objdump (GNU Binutils for Debian) 2.40

== 828 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
helgrind/tests/tc24_nonzero_sem          (stderr)

Fedora release 40 (Forty) Linux 6.8.11-300.fc40.ppc64le #1 SMP Mon May
27 14:48:15 UTC 2024 GNU C Library (GNU libc) stable release version
2.39. g++ 14.1.1 binutils 2.41

== 773 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
helgrind/tests/getaddrinfo               (stderr)

Fedora release 40 (Forty) Linux 6.1.15-legacy-k1 #9 SMP PREEMPT Mon
Aug 12 15:06:24 UTC 2024 GNU C Library (GNU libc) stable release
version 2.39. g++ 14.1.1 binutils 2.42

== 750 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 0 post failures ==
gdbserver_tests/hgtls                   

Fedora release 40 (Forty) Linux 6.12.13-100.fc40.s390x #1 SMP Sat Feb
8 16:54:58 UTC 2025 GNU C Library (GNU libc) stable release version
2.39. g++ 14.2.1 binutils 2.41

== 888 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
drd/tests/getaddrinfo                    (stderr)

Fedora release 40 (Forty) Linux 6.13.9-100.fc40.aarch64 gcc (GCC)
14.2.1 20240912 (Red Hat 14.2.1-3) GNU objcopy version 2.41-38.fc40
iconv (GNU libc) 2.39

== 760 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)

fedora-latest gcc (GCC) 14.2.1 20250110 (Red Hat 14.2.1-7) GNU objcopy
version 2.43.1-5.fc41 iconv (GNU libc) 2.40

== 841 tests, 4 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
drd/tests/fork-parallel                  (stderr)
drd/tests/fork-serial                    (stderr)
drd/tests/threaded-fork-vcs              (stderr)
drd/tests/threaded-fork                  (stderr)

Ubuntu 24.04.1 LTS Linux 6.8.0-52-generic #53.1-Ubuntu SMP
PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 GNU C Library
(Ubuntu GLIBC 2.39-0ubuntu8.3) stable release version 2.39. g++ 14.2.0
GNU objdump (GNU Binutils) 2.43.1

== 752 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 0 post failures ==
gdbserver_tests/hgtls                    (stdoutB)
memcheck/tests/linux/timerfd-syscall     (stderr)

Armbian 25.2.3 bookworm Linux 6.12.20-current-rockchip GNU C Library
(Debian GLIBC 2.36-9+deb12u10) stable release version 2.36. g++ 12.2.0
GNU objdump (GNU Binutils for Debian) 2.40

== 757 tests, 46 stderr failures, 6 stdout failures, 0 stderrB failures, 0 stdoutB failures, 5 post failures ==
memcheck/tests/dw4                       (stderr)
memcheck/tests/leak_cpp_interior         (stderr)
memcheck/tests/linux/stack_changes       (stderr)
memcheck/tests/varinfo2                  (stderr)
memcheck/tests/varinfo4                  (stderr)
memcheck/tests/varinfo5                  (stderr)
memcheck/tests/varinfo6                  (stderr)
memcheck/tests/varinforestrict           (stderr)
memcheck/tests/vbit-test/vbit-test       (stderr)
helgrind/tests/annotate_rwlock           (stderr)
helgrind/tests/bar_bad                   (stderr)
helgrind/tests/bug392331                 (stderr)
helgrind/tests/free_is_write             (stderr)
helgrind/tests/hg02_deadlock             (stderr)
helgrind/tests/hg03_inherit              (stderr)
helgrind/tests/hg04_race                 (stderr)
helgrind/tests/hg04_race_h9              (stderr)
helgrind/tests/hg05_race2                (stderr)
helgrind/tests/locked_vs_unlocked1_fwd   (stderr)
helgrind/tests/locked_vs_unlocked1_rev   (stderr)
helgrind/tests/locked_vs_unlocked2       (stderr)
helgrind/tests/locked_vs_unlocked3       (stderr)
helgrind/tests/pth_barrier1              (stderr)
helgrind/tests/pth_barrier2              (stderr)
helgrind/tests/pth_barrier3              (stderr)
helgrind/tests/pth_destroy_cond          (stderr)
helgrind/tests/rwlock_race               (stderr)
helgrind/tests/tc01_simple_race          (stderr)
helgrind/tests/tc05_simple_race          (stderr)
helgrind/tests/tc06_two_races            (stderr)
helgrind/tests/tc06_two_races_xml        (stderr)
helgrind/tests/tc09_bad_unlock           (stderr)
helgrind/tests/tc14_laog_dinphils        (stderr)
helgrind/tests/tc16_byterace             (stderr)
helgrind/tests/tc19_shadowmem            (stderr)
helgrind/tests/tc20_verifywrap           (stderr)
helgrind/tests/tc21_pthonce              (stderr)
helgrind/tests/tc22_exit_w_lock          (stderr)
massif/tests/bug469146                   (post)
massif/tests/new-cpp                     (post)
massif/tests/overloaded-new              (post)
none/tests/arm/v8crypto_a                (stdout)
none/tests/arm/v8crypto_a                (stderr)
none/tests/arm/v8crypto_t                (stdout)
none/tests/arm/v8crypto_t                (stderr)
none/tests/arm/v8fpsimd_a                (stdout)
none/tests/arm/v8fpsimd_a                (stderr)
none/tests/arm/v8fpsimd_t                (stdout)
none/tests/arm/v8fpsimd_t                (stderr)
none/tests/arm/v8memory_a                (stdout)
none/tests/arm/v8memory_a                (stderr)
none/tests/arm/v8memory_t                (stdout)
none/tests/arm/v8memory_t                (stderr)
exp-bbv/tests/arm-linux/ll               (stderr)
exp-bbv/tests/arm-linux/ll               (post)
exp-bbv/tests/arm-linux/million          (stderr)
exp-bbv/tests/arm-linux/million          (post)

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

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

On 4/24/25 03:59, Mark Wielaard wrote:
> An RC2 tarball for 3.25.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC2.tar.bz2
> (md5sum = 4e53a0a1a8d1404e77e6c45015eeb472)
> (sha1sum = ba482eeeb89dd271006f59b09f01048be6530a53)
> https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC2.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

All OK on

FreeBSD amd64

FreeBSD arm64

illumos amd64

No time to test anything else.