valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Valgrind-3.27.0 is available

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

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

This release brings two new options for helgrind (--show-events and
--track-destroy), several new SSE4.1 instruction for x86 (32 bit),
support for new s390x z/Architecture features from the 15th edition,
integrated binutils objdump for s390x disassembly, support for new
linux syscalls, address space manager support for tracking linux
kernel lightweight guard pages, freebsd support for 16.0-CURRENT,
macOS supported up to version 13 Ventura (Intel only), and new client
requests macros (VALGRIND_REPLACES_MALLOC and VALGRIND_GET_TOOLNAME).

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 494 commits
by 12 people, fixing 62 bugs.

Happy and productive debugging and profiling,

-- The Valgrind Developers

Release 3.27.0 (20 Apr 2026)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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, X86/macOS, AMD64/macOS. 
X86/FreeBSD, AMD64/FreeBSD and ARM64/FreeBSD. There is preliminary support
for nanoMIPS/Linux. macOS is supported up to version 13 Ventura (amd64 only).

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

* There are two new client requests

  - VALGRIND_REPLACES_MALLOC Returns 1 if the tool replaces malloc
    (e.g., memcheck).  Returns 0 if the tool does not replace malloc
    (e.g., cachegrind and callgrind) or if the executable is not
    running under VALGRIND.

  - VALGRIND_GET_TOOLNAME Get the running tool name as a string. Takes
    two arguments, an input buffer pointer and the length of that
    buffer. Returns the required length (including terminating nul)
    for the tool name. Returns 0 and the contents supplied buffer are
    not modified if not running under Valgrind.

  See also the full description in the valgrind.h header file or the
  in The Client Request mechanism section of the Valgrind User Manual.

* linux lightweight guard pages (madvise MADV_GUARD_INSTALL) supported

  glibc 2.42+ (with linux 6.13+) uses MADV_GUARD_INSTALL to setup
  stack guard pages. These lightweight guard pages are now supported
  under valgrind. By default, Valgrind can handle to up to 500 madvise
  guard pages. With thread heavy workloads the default value might not
  be sufficient. Use --max-guard-pages=N to provide a different limit.
  If --max-guard-pages is not set explicitly, then it will default to
  the --max-threads setting.

* --num-callers now has a minimum value of 2.

  This is a breaking change. See
  https://bugs.kde.org/show_bug.cgi?id=515183#c13
  for full details.

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

* x86: Support for SSE4.1 instructions has been ported from AMD64 to
  (32bit) x86. This is ongoing work. Currently the following SSE4.1
  instructions are supported BLENDPD BLENDPS BLENDVPD BLENDVPS
  MOVNTDQA MPSADBW PBLENDVB PBLENDW PCMPEQQ PINSRD PMAXSB PMAXSD
  PMAXUD PMAXUW PMINSB PMINSD PMINUD PMINUW PMULLD PTEST.
  Bug #518222 tracks further progress.

* s390x: Machine models older than z196 are no longer supported.

* s390x: Support new z/Architecture features from the 15th edition.  In
  particular this enables running binaries compiled with `-march=arch15'
  or `-march=z17' and exploiting the new MSA extensions 10-13.

* Support for the following macOS versions has been added
  10.13 High Sierra (bug fixes)
  10.14 Mojave
  10.15 Catalina
  11.0  Big Sur (Intel only)
  12.0  Monterey (Intel only)
  13.0  Ventura (Intel only, preliminary)

* The Linux Test Project (LTP) v20260130 was integrated. New linux
  syscall wrappers for file_getattr, file_setattr, lsm_get_self_attr,
  lsm_set_self_attr, lsm_list_modules were added.

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

* Helgrind:

  - New debug option --show-events=0|1|2. Controls tracing of internal
    Helgrind synchronization, threading and memory events. At level 1,
    Helgrind prints a trace of its synchronization, threading and memory
    events. At level 2, additional memory events are also traced. The
    default value of 0 disables tracing.

  - New option --track-destroy=no|yes|all. Checks for missing
    pthread_mutex_destroy and pthread_rwlock_destroy calls. With yes,
    Helgrind warns when pthread_mutex_init or pthread_rwlock_init is called
    on the address of a live (undestroyed) lock. With all, Helgrind also
    reports undestroyed locks at process exit. --track-destroy does not track
    locks that use static initializers.

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

126256  (fnop) vex x86->IR: unhandled instruction bytes: 0xD9 0xD0 0x31 0xC0
228343  none/tests/darwin/bug228343 fails on OS X
233298  MEMPOOL_FREE not reflected in heap summary
253436  vex amd64->IR: unhandled instruction bytes: 0xF2 0xA6 (repne cmps)
258140  Valgrind on OS X always reports some memory "still reachable"
390754  unhandled amd64-darwin syscall: unix:216 (open_dprotected_np)
406674  False positive when reading bitfield value on code compiled with
        clang 7.0
413369  unhandled amd64-darwin syscall: unix:151 (getpgid)
413410  unhandled amd64-darwin syscall: mach:50 (on macOS 10.15)
487055  memcheck/tests/x86-linux/scalar fails running in Docker
503238  s390x: Support miscellaneous-instruction-extensions facility 4
503239  s390x: Support vector-enhancements facility 3
503240  s390x: Support MSA extensions 10, 11, and 12
509562  s390x: Define minimum required machine model
510416  Missing syswraps for file_getattr and file_setattr
510563  Add missing syswraps for lsm_get_self_attr and lsm_set_self_attr
510864  Add SSE4.1 PMAXSD and PMINSD instructions support for 32-bit x86
511329  Darwin and FreeBSD: Move setting of carry flag out of
        ML_(do_syscall_for_client_WRK)
511461  Darwin 17 (MacOS X 10.13) memcheck issues
511713  Refactor syscall argument handling
511717  gdbserver (valgrind_read_memory) the 'impossible' happened:
        Killed by fatal signal (SIGSEGV)
511972  valgrind-3.26.0 tests fail to build on upcomig gcc-16:
        unrecognized command-line option
        '-Wno-alloc-size-larger-than=18446744073709551615'
512030  s390x: bfp-convert testcase fails
512037  malloc trace does not print free size or alignment
512291  Valgrind on Solaris should drop support for long gone /dev/crypto
        framework
512571  regtest problems with darwin dsymutil
512873  Add SSE4.1 min/max instructions for x86 32 bit
513257  Add missing syswraps for lsm_list_modules
513522  m_libcassert.c: 'ordered comparison of pointer with integer zero'
        compiler warning
513475  Add SSE4.1 PMULLD instruction for x86 32 bit
513598  Helgrind should detect locks without pthread_{rwlock,mutex}_destroy
        being called - Assertion 'lk->kind == LK_rdwr' failed.
514094  readlink("/proc/self/exe") overwrites buffer beyond its return value
514206  Assertion '!sr_isError(sr)' failed - mmap fd points to an open
        descriptor to a PCI device
514297  Track madvise MADV_GUARD_INSTALL in address space manager
514343  Add a valgrind.h macro VALGRIND_REPLACES_MALLOC
514596  Add SSE4.1 BLENDPD instruction for x86 32 bit
514613  Unclosed leak_summary/still_reachable tag in xml output
514659  ltp 20250930 vs linux 6.18.3 doesn't build
514762  Many "Bad file descriptor" messages when using --track-fds=yes and
        -d on systems without /proc
515183  Error occurred while executing the command
        `valgrind --num-callers=1 ./hello_world`
515265  Add SSE4.1 BLENDPS and PBLENDW instructions for x86 32 bit
516223  Add SSE4.1 PBLENDVB, BLENDVPS and BLENDVPD
        instructions for x86 32 bit
515612  Sanity check VG_(realpath) and VG_(readlink) return values
515731  Distinguish between realloc functions in realloc size 0 error messages
515810  Update the LTP version in valgrind testsuite to 20260130
515992  Add FreeBSD /proc virtualisation for cmdline and file
516090  Regression : Linux FreeBSD and Darwin: refactor *at syscall dirfd checks
516225  Add MOVNTDQA SSE4.1 support for x86
516289  illumos lsframe2 regtest fails
516748  Incorrect use of SET_STATUS_Failure for syscall wrappers that return
        error codes rather than -1 on error
517455  Add PCMPEQQ SSE4.1 support for x86
517697  Implement CLRSSONSTACK and SETUJMPBUF handling on Solaris.
517748  Add ability to redirect global functions to Darwin
517840  Add PTEST SSE4.1 support for x86
518216  Add SSE4.1 MPSADBW instruction support for x86 32 bit
518076  FreeBSD: add syscall wrapper for renameat2
518078  Configure should accept names for GDB other than "gdb"
518159  pth_once issues on Darwin
518482  FreeBSD: assert in parse_procselfmaps when built with GNU binutils
518609  Setting double verbose interferes with symbol loading (FreeBSD 16)
518778  Valgrind LTP testsuite fails to compile on Fedora 44+
518951  LTP testcase fsconfig02 fails under Valgrind

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.27.0.RC1: 13 Apr 2026)
(3.27.0.RC2: 17 Apr 2026)

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

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

Hi Abhay,

On Sun, Apr 19, 2026 at 12:25:02AM +0530, Abhay Kandpal via Valgrind-developers wrote:
> I did testing again for valgrind-3.27.0.RC2.tar.bz2 on all setup like P10 LE, P9 LE/BE, P8 LE.
> 
> I found the results are mostly the same or slightly improved like for P9 BE, below cases are fixed in RC2.
> none/tests/fdleak_ipv4                           (stderr)
> none/tests/fdleak_ipv4_xml                       (stderr)
> none/tests/fdleak_ipv4_xml                       (stdout)
> 
> Versions used are the same as during RC1 testing which I already shared in my previous mail.

Great. Thanks.

> Technical Analysis:
> -------------------
> 
>  Valgrind's configure script detects AltiVec by parsing LD_SHOW_AUXV output:
> 
>     if env LD_SHOW_AUXV=1 true | grep ^AT_HWCAP | grep -q -w altivec
>     then
>         HWCAP_HAS_ALTIVEC='yes'
>     fi
> 
> 
> With glibc 2.41, LD_SHOW_AUXV prints human-readable capability names:
> 
>     AT_HWCAP: true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32
> 
> 
> With glibc 2.42, it only prints raw hex values:
> 
>     AT_HWCAP: 0xdc0065c2
> 
> 
> 
> The hex value 0xdc0065c2 does have the AltiVec bit set (bit 28 = 0x10000000), confirming
> that the hardware supports AltiVec.
> 
> 
> On BE systems, VGCONF_ARCH_SEC='ppc32' causes the ppc32 test suite to be built. Without HWCAP_HAS_ALTIVEC='yes',
> the -maltivec flag is omitted, and testVMX.c fails to compile.
> 
> LE systems are unaffected because VGCONF_ARCH_SEC is empty and ppc32 tests are not built.

Wow, interesting failure. And nice analysis.

> Workaround applied: I manually set HWCAP_HAS_ALTIVEC='yes' in the
> configure script on P10/P8 BE systems to unblock testing. After
> that, make and make regtest completed successfully. Results were
> same as RC1.

Thanks. Given there is a workaround, this is only with make regtest
and on a secondary arch which isn't super popular I think we won't try
to fix this before the release.
 
> I still need to investigate whether this change in glibc 2.42 is intentional.

Yes, this is slightly surprising change in behaviour for glibc
LD_SHOW_AUXV=1 I don't see anything in NEWS that would explain the
change.

> Currently, Valgrind's configure.ac handles only the string format, not hex. Do we need to handle this in configure.ac?

To be honest I think these AC_HWCAP_CONTAINS_FLAG usage in configure
are testing the wrong thing. They look whether the hardware supports some
feature, but then use it to provide a flag to gcc for building
something for that feature. So instead of a runtime check we should
add a compiler flag check (and then do the runtime check before
running the test).

> Otherwise valgrind 3.27.0 RC2 is good to go.

Thanks, I'll prep the final release now.

Cheers,

Mark

[Valgrind-users] Anticipating valgrind 3.27.0

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

We'll release Valgrind 3.27.0 later today. While making sure the NEWS
file was up to date I wrote about all the contributions made this
release. https://mastodon.nl/@mjw/tagged/valgrind

https://gnu.wildebeest.org/blog/mjw/2026/04/20/anticipating-valgrind-3-27-0/

Thanks all, and apologies if I missed something or someone.

Aaron Merey added two new options to helgrind.

To control helgrind tracing of internal synchronization, threading and
memory events use --show-events=1|2|3.

Use --track-destroy=no|yes|all to checks for missing
pthread_mutex_destroy and pthread_rwlock_destroy calls. With yes,
helgrind warns when pthread_mutex_init or pthread_rwlock_init is called
on the address of a live (undestroyed) lock. With all, Helgrind also
reports undestroyed locks at process exit.

Valgrind has separate VEX IR translators for AMD64 and x86 (32 bit)
code. While the AMD64 translator has seen support for new encodings and
instruction sets, the x86 translator has not.

Alexandra Hájková decided to port the SSE4.1 instruction set from the
AMD64 translator to the x86 translator and add backend support. This is
ongoing work, see the bug dependency tree
https://bugs.kde.org/showdependencytree.cgi?id=518222

But many more 32bit programs using SSE4.1 should now run under
Valgrind.

Andreas Arnez and Florian Krohm did a lot of work on the s390x support.

Andreas added support for new s390x z/Architecture features from the
15th edition. This enables running binaries compiled with -march=arch15
or -march=z17 and exploiting the new MSA extensions 10-13.

Florian	Krohm integrated binutils objdump for s390x disassembly in
VEX. And did a lot of s390x code and facilities cleanups.

s390x machine models older than z196 are no longer supported.

Andreas also showed there are still meaningful optimizations to be made
on how memcheck tracks undefinedness bits as outlined in the original
"Using Valgrind to detect undefined value errors with bit-precision"
https://valgrind.org/docs/memcheck2005.pdf paper.

His optimization of memcheck instrumenting a bitwise AND/OR with a
constant is clever and simplifies the generated code:
https://sourceware.org/cgit/valgrind/commit/?id=8514763a215f863bc52400991eba332df115eaea

Martin Cermak maintains the Linux Test Program (LTP) valgrind
integration, which checks our syscall wrappers work correctly. And he
makes sure newer linux syscalls are wrapped. Valgrind 3.27.0 adds
support for file_getattr, file_setattr, lsm_get_self_attr,
lsm_set_self_attr, lsm_list_modules. And corrects various syscall and
ioctl corner cases.

Martin also added Valgrind address space manager support for tracking
linux kernel lightweight guard pages, created through madvise
(MADV_GUARD_INSTALL).

These guard pages are very low overhead for the kernel because they
aren't tracked as separate VMAs and don't show up in the process proc
maps. But Valgrind does still need to know whether the addresses are
accessible. A new --max-guard-pages option controls the memory Valgrind
reserves for tracking these pages.

Paul Floyd had more commits than all others combined for this release.
Paul takes care of the alternative toolchains, Solaris/illumos, FreeBSD
and Darwin/MacOS ports.

Tested Oracle Solaris 11.4, OpenIndiana Hipster and OmniOS.

FreeBSD works on both amd64 and arm64, support for 16.0-CURRENT has
been added.

Supported MacOS versions, 10.13 (bug fixes), 10.14, 10.15, 11.0 (Intel
only), 12.0 (Intel only), 13.0 (Intel only, preliminary). No arm64
support yet.

A lot of code in valgrind 3.27.0 to support MacOS was previously
maintained by Louis Brunner out of tree
https://github.com/LouisBrunner/valgrind-macos

There are two new client requests (macros defined in valgrind.h)
https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-
adv.clientreq

- VALGRIND_REPLACES_MALLOC Returns 1 if the tool replaces malloc (e.g.,
memcheck). Returns 0 if the tool does not replace malloc (e.g.,
cachegrind and callgrind) or if the executable is not running under
Valgrind.

- VALGRIND_GET_TOOLNAME Get the running tool name as a string. Takes
two arguments, an input buffer pointer and the length of that buffer.

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

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

On 2026-04-18 03:05, Mark Wielaard wrote:
> An RC2 tarball for 3.27.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2
> (md5sum = 64b955764abeb80fd3e0b6287e596750)
> (sha1sum = a52b15d2f75619762fb1c5007e7c2c26d7e3711e)
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2.asc
> Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt
>
> 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.27.0 release is scheduled for Mon Apr 20.

Hi Mark

A bit shorter this time, full details for Darwin though.

FreeBSD - OK


Solaris/illumos OK


macOS

macOS 10.13 OK

macOS 10.14 - massif tests now OK

== 748 tests, 38 stderr failures, 4 stdout failures, 7 stderrB failures, 
7 stdoutB failures, 2 post failures ==

macOS 10.15

== 748 tests, 36 stderr failures, 4 stdout failures, 7 stderrB failures, 
7 stdoutB failures, 2 post failures ==

macOS 11

== 748 tests, 43 stderr failures, 4 stdout failures, 8 stderrB failures, 
5 stdoutB failures, 2 post failures ==

macOS 12

== 749 tests, 45 stderr failures, 4 stdout failures, 7 stderrB failures, 
5 stdoutB failures, 2 post failures ==

macOS 13
== 749 tests, 73 stderr failures, 8 stdout failures, 8 stderrB failures, 
6 stdoutB failures, 5 post failures ==

A+

Paul

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

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

An RC2 tarball for 3.27.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2
(md5sum = 64b955764abeb80fd3e0b6287e596750)
(sha1sum = a52b15d2f75619762fb1c5007e7c2c26d7e3711e)
https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2.asc
Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt

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.27.0 release is scheduled for Mon Apr 20.

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

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

Hi Abhay,

On Thu, 2026-04-16 at 12:51 +0530, Abhay Kandpal wrote:
> We tested Valgrind 3.27 RC1 across Power systems.

Thanks so much for testing. Would you be able to report the kernel,
gcc, binutils and glibc versions installed on the system?

>  memcheck/tests/linux/ioctl_procmap_query         (stdout)
> memcheck/tests/linux/ioctl_procmap_query         (stderr)
> memcheck/tests/replaces_malloc_client_req        (stdout)
> memcheck/tests/replaces_malloc_client_req        (stderr)

> Overall, several previously failing tests are now fixed.
> A small number of new failures are observed, primarily on BE systems
> and older processors, and are not considered release blockers.

Results indeed look good. The two that worry me slightly are:

memcheck/tests/linux/ioctl_procmap_query
memcheck/tests/replaces_malloc_client_req

They only fail on BE or older systems, but if you could post the
.stdout/.stderr[.diff] files we could see what is going on there.

> From our side, there are no blockers for the 3.27 release.

Great.

Cheers,

Mark

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

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

On 2026-04-14 03:07, Mark Wielaard wrote:
> An RC1 tarball for 3.27.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2
> (md5sum = bd95111c1a9f81f136c5e4e2c62b493e)
> (sha1sum = 0eefb3a7d86a3bd0154480db3d2173bb8bd6d7c1)
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2.asc
> Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt
>
> 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
>
> An RC2 should be available Fri Apr 17
> The final 3.27.0 release is scheduled for Mon Apr 20.

Hi all,

Part 3, Darwin.

A few issues, on macOS 11 to 13 I get.

m_mach/dyld_cache.c:45:10: fatal error: 'priv_dyld_internals.h' file not 
found #include "priv_dyld_internals.h" // CACHE_MAGIC_*, 
dyld_cache_header, etc ^~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.

I just pushed a fix for that. There are a load of unexpected Massif 
failures on macOS 10.14. Not serious, I need to add more ignore functions.

General Darwin overview. In short, the Darwin port has gone from barely 
building on 10.13 to being half decent. There is still a great deal to do.

Good: many fixes for 10.13, added 10.14, 10.15, 11, 12, 13

Bad: No arm64 support yet - building Valgirnd on arm64 is even more 
difficult than on amd64. Helgrind and DRD have some encapsulation issues 
(things like internal mutexes, clearing or reinitialising mutexes/locks 
on fork). Small C and C++ only tests work quite well (like regtest). 
Real-world GUI apps and apps using Apple frameworks work very badly. At 
the very least they require huge numbers of suppressions. macOS 13 has 
about twice as many regtest failures as previous macOS versions (~80 
compared to ~40). Analysis is ongoing. x86 has unsupported opcode issues 
- a few on macOS 10.13 and macOS 10.14 x86 is unusable because they are 
used in dyld (the dynamic loader). macOS 10.15 dropped x86 support. No 
access to macOS 14 and later amd64 hardware or VMs. No access to macOS 
11 arm64. 12 and later can be installed in VMs fairly easily it seems. 
For regtest: Some problems with clang debuginfo. Many leaks on startup 
mess up memcheck leak tests and DHAT.

macOS 10.13 == 806 tests, 36 stderr failures, 12 stdout failures, 0 
stderrB failures, 0 stdoutB failures, 2 post failures == macOS 10.14 == 
748 tests, 50 stderr failures, 4 stdout failures, 8 stderrB failures, 7 
stdoutB failures, 32 post failures ==

macOS 10.15 == 748 tests, 36 stderr failures, 4 stdout failures, 7 
stderrB failures, 7 stdoutB failures, 2 post failures ==

macOS 11 macOS 12 macOS 13 Build failed

A+

Paul

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

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

On 2026-04-14 03:07, Mark Wielaard wrote:
> An RC1 tarball for 3.27.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2
> (md5sum = bd95111c1a9f81f136c5e4e2c62b493e)
> (sha1sum = 0eefb3a7d86a3bd0154480db3d2173bb8bd6d7c1)
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2.asc
> Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt
>
> 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
>
> An RC2 should be available Fri Apr 17
> The final 3.27.0 release is scheduled for Mon Apr 20.

Hi again

Second of three responses. FreeBSD.

In short, all looking good. The development version of FreeBSD always 
has some issues. It's nice to be able to access a couple of FreeBSD 
servers on GCC cfarm.

When FreeBSD 14.4-RELEASE came out there were no problems. 16.0-CURRENT 
(roughly the git head version) has been another kettle of fish. Two big 
problems, one due to switching to using the LLVM toolchain (instead of 
GNU ld.bfd) to generate split .debug files. The other, not specific to 
16 but I came across the issue on cfarm 16.0 servers, is that if GNU 
paltform-binutils is installed then clang will default to using ld.bfd 
rather than ld.lld. That broke my assumptions in parse_procselfmaps(). 
All that should be fixed.

amd64
======

FreeBSD 14.3-RELEASE-p8 amd64
== 964 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 1 
stdoutB failure, 0 post failures ==

FreeBSD 14.4-RELEASE-p1
== 941 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 
0 stdoutB failures, 0 post failures ==

FreeBSD 15.0-RELEASE-p5 amd64
== 967 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 1 
stdoutB failure, 0 post failures ==

FreeBSD 16.0-CURRENT amd64
== 961 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 
1 stdoutB failure, 0 post failures ==

arm64
=====

FreeBSD 15.0-RELEASE-p5 arm64
== 809 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 
stdoutB failures, 0 post failures ==

FreeBSD 16.0-CURRENT arm64
== 803 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 
1 stdoutB failure, 0 post failures ==

There are about 3 tests that are flaky and I see them failing 
always/regularly.

I need to look at drd/tests/tls_threads  on 16.0-CURRENT.


Next up, Darwin.

A+

Paul

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

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

On 2026-04-14 03:07, Mark Wielaard wrote:
> An RC1 tarball for 3.27.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2
> (md5sum = bd95111c1a9f81f136c5e4e2c62b493e)
> (sha1sum = 0eefb3a7d86a3bd0154480db3d2173bb8bd6d7c1)
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2.asc
> Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt
>
> 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
>
> An RC2 should be available Fri Apr 17
> The final 3.27.0 release is scheduled for Mon Apr 20.

Hi

First of 3 replies, probably.

I'll start with Solaris and illumos. In short, all is well and even a 
bit better than 3.26.

Oracle Solaris 11.4 CBE 11.4.90
== 955 tests, 44 stderr failures, 1 stdout failure, 1 stderrB failure, 4 
stdoutB failures, 5 post failures ==
Most fails are due to a warning about reading debuginfo from 
libsocket.so.1 and libnsl.so.1. These are now just redirects to 
libc. I've retired my old HP workstation that was running Solaris 11.3 
so I don't use Oracle Solaris much at all these days. I fixed one nasty 
bug in the client stack creation (517697) and Oracle provided a patch 
for getsetcontext on the the latest Solaris versions (517697).  
Otherwise it looks mainly like a lack of care and attention - minor 
callstack diffs.

OpenIndiana Hipster 2025.10
== 918 tests, 5 stderr failures, 0 stdout failures, 1 stderrB failure, 3 
stdoutB failures, 0 post failures ==

OmniOS r151057
== 938 tests, 6 stderr failures, 0 stdout failures, 1 stderrB failure, 3 
stdoutB failures, 0 post failures ==

For both of the 2 illumos spins above there are 3 gdbserver tests that 
always fail and 3 DRD pthread_barrier tests that fail often but are 
intermittent.

Lastly there's one Helgrind test that was failing due to a 
pthread_rwlock_init callstack diff. I fixed that yesterday.

Next up, FreeBSD.

A+

Paul

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

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

An RC1 tarball for 3.27.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2
(md5sum = bd95111c1a9f81f136c5e4e2c62b493e)
(sha1sum = 0eefb3a7d86a3bd0154480db3d2173bb8bd6d7c1)
https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2.asc
Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt

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

An RC2 should be available Fri Apr 17
The final 3.27.0 release is scheduled for Mon Apr 20.

[Valgrind-users] introducing sanity.nvim: a valgrind plugin for neovim

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

Hi,

Does anyone here use neovim with valgrind? Because I'm a heavy user of
both, I've developed a neovim plugin to ingest valgrind/helgrind logs
to populate the quickfix list and provide some other nice
integrations:

https://github.com/dlyongemallo/sanity.nvim

It also works with sanitizer logs.

If you use neovim and valgrind together (and I realise the
intersection might be very small), please give it a try and let me
know what you think.

Thanks, and have a great weekend.

-- 
David Yonge-Mallo

Re: [Valgrind-users] Illegal instruction error in some versions of valgrind

[Steve E. <st...@ed...>]

Thanks.

On 25/02/26 1:43 am, Paul Floyd via Valgrind-users wrote:
>
> Hi
>
> On 24/02/2026 04:22, Steve Edmonds wrote:
>>
>> vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x38 0x39
>>
> That ought to work
>
>    case 0x39:
>    case 0x3D:
>       /* 66 0F 38 39 /r = PMINSD xmm1, xmm2/m128
>          Minimum of Packed Signed Double Word Integers (XMM)
>          66 0F 38 3D /r = PMAXSD xmm1, xmm2/m128
>          Maximum of Packed Signed Double Word Integers (XMM)
>       */
>       if (have66noF2noF3(pfx) && sz == 2) {
>          /* FIXME: this needs an alignment check */
>          Bool isMAX = opc == 0x3D;
>          delta = dis_SSEint_E_to_G(
>                     vbi, pfx, delta,
>                     isMAX ? "pmaxsd" : "pminsd",
>                     isMAX ? Iop_Max32Sx4 : Iop_Min32Sx4,
>                     False
>                  );
>          goto decode_success;
>       }
>       break;
>
> It was also fairly recently added to x86 by Alexandra Hajkova. You 
> will need to build Valgrind from source or wait for version 3.27 for that.
>
> Would it be possible for me to build 'quasar'? Is it this 
> https://quasar.dev/start/quasar-cli/ ?
>
This is the quasar (https://quasaraccounting.com/) and I have an old 
non-deb version with decades of data.
I might look at building Valgrind and see what happens.
Steve

Re: [Valgrind-users] Illegal instruction error in some versions of valgrind

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

Hi

On 24/02/2026 04:22, Steve Edmonds wrote:
>
> vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x38 0x39
>
That ought to work

    case 0x39:
    case 0x3D:
       /* 66 0F 38 39 /r = PMINSD xmm1, xmm2/m128
          Minimum of Packed Signed Double Word Integers (XMM)
          66 0F 38 3D /r = PMAXSD xmm1, xmm2/m128
          Maximum of Packed Signed Double Word Integers (XMM)
       */
       if (have66noF2noF3(pfx) && sz == 2) {
          /* FIXME: this needs an alignment check */
          Bool isMAX = opc == 0x3D;
          delta = dis_SSEint_E_to_G(
                     vbi, pfx, delta,
                     isMAX ? "pmaxsd" : "pminsd",
                     isMAX ? Iop_Max32Sx4 : Iop_Min32Sx4,
                     False
                  );
          goto decode_success;
       }
       break;

It was also fairly recently added to x86 by Alexandra Hajkova. You will 
need to build Valgrind from source or wait for version 3.27 for that.

Would it be possible for me to build 'quasar'? Is it this 
https://quasar.dev/start/quasar-cli/ ?

Regards

Paul

Re: [Valgrind-users] Illegal instruction error in some versions of valgrind

[Steve E. <st...@ed...>]

On 27/01/2026 20:17, Paul Floyd via Valgrind-users wrote:
>
> On 27/01/2026 01:06, Steve Edmonds wrote:
>> Hi. I have just joined the group to see if I can resolve a long 
>> standing issue with valgrind on Opensuse.
>> I have been using some accounting software for many years, initially 
>> it ran fine and then at some point it started causing a segmentation 
>> fault.
>>
>> I then started using it with valgrind, successful with some versions 
>> of valgrind and not with others, when it fails I get the following 
>> before termination and core dump.
>>
>> ==199084==  Illegal opcode at address 0x453BC82
>> ==199084==    at 0x453BC82: write_vec (xcb_conn.c:262)
>>
>> Using valgrind from the latest Leap 15.6 and 16.0 repositories fails 
>> (valgrind-3.26.0-355.d_t.2.x86_64.rpm, 3.24.0-150600.3.3.1, 
>> 3.22.0-150600.1.3, 3.24.0-160000.2.2 and 3.25.1-160000.1.1) I do have 
>> the software running successfully with versions 3.25.1-350.d_t.1 (on 
>> Leap 15.6) and 3.13.0-lp150.4.61-x86_64 (on Leap 15.0 in a VM). I am 
>> trying to get to grips with what might determine a successful version 
>> of valgrind, I can no longer locate the rpm for 3.25.1-350.d_t.1 to 
>> try on Leap 16.0 and quite happy to build from source if there is 
>> some configuration in the source that will resolve this issue.
>
> Hi Steve
>
> Trying older Valgrind versions is unlikely solve the problem.
>
> What application are you trying to run under Valgrind? I just tried 
> Valgrind 3.25.1 on openSUSE LEAP 16.0 running kwrite and there were no 
> major issues.
>
> In gdb (with kwrite again) that piece of code looks like
>
> 261     n = *count;
> 262     if (n > IOV_MAX)
> 263 n = IOV_MAX;
>
> Nothing unusual in the assembler, like like it is using SSE instructions.
>
> Can you also post the op-code bytes that Valgrind fails to handle?
>
> Lastly, have you built your own copy of libxcb.so.1? If so, did you 
> use any GCC options like -march? There are a few amd64 CPU features 
> that like AVX512 that Valgrind does not support.
>
> Regards
>
> Paul
Hi Paul.
Are the op-code bytes in the information below?
I have not built my own copy of libxcb.so.1

On Leap 16.0 I get the following, the application fails to load. 
valgrind installed is 3.25.1-160000.1.1. Same for X11 and Wayland

steve@linux-qw83:~> valgrind quasar
==18853== Memcheck, a memory error detector
==18853== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==18853== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info
==18853== Command: quasar
==18853==
vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x38 0x39
==18853== valgrind: Unrecognised instruction at address 0x453bc82.
==18853==    at 0x453BC82: UnknownInlinedFun (xcb_conn.c:262)
==18853==    by 0x453BC82: _xcb_conn_wait.part.0 (xcb_conn.c:553)
==18853==    by 0x453BF4C: UnknownInlinedFun (xcb_out.c:469)
==18853==    by 0x453BF4C: _xcb_out_send (xcb_out.c:470)
==18853==    by 0x453EE4A: UnknownInlinedFun (xcb_conn.c:166)
==18853==    by 0x453EE4A: xcb_connect_to_fd (xcb_conn.c:385)
==18853==    by 0x453F909: xcb_connect_to_display_with_auth_info 
(xcb_util.c:565)
==18853==    by 0x453FA3D: xcb_connect (xcb_util.c:522)
==18853==    by 0x40DADAA: _XConnectXCB (xcb_disp.c:78)
==18853==    by 0x40CC3FA: XOpenDisplay (OpenDis.c:129)
==18853==    by 0x86EEFE2: qt_init_internal__FPiPPcP9_XDisplayUlUl (in 
/opt/quasar/bin/quasar)
==18853==    by 0x86EFF83: qt_init__FPiPPcQ212QApplication4Type (in 
/opt/quasar/bin/quasar)
==18853==    by 0x873145B: 
construct__12QApplicationRiPPcQ212QApplication4Type (in 
/opt/quasar/bin/quasar)
==18853==    by 0x87312F7: __12QApplicationRiPPc (in /opt/quasar/bin/quasar)
==18853==    by 0x818B585: main (in /opt/quasar/bin/quasar)

On Leap 15.0 running in a VM.
I get the following where the application runs ok.
  steve@linux-b1cb:~> valgrind quasar
==9455== Memcheck, a memory error detector
==9455== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9455== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9455== Command: quasar
==9455==

On Leap 15.6 the application loads, the installed valgrind is 
3.25.1-350.d_t.1
steve@rnd2:~> valgrind quasar
==6438== Memcheck, a memory error detector
==6438== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==6438== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info
==6438== Command: quasar

I am not sure where to start to debug this.
This application has worked on and off with valgrind from before Leap 
42.3. Some times it wouldn't work, then there would be an update to 
valgrind and it would work so I would stick with that version until 
until a distribution update and go through it all again.

Cheers,
Steve

Re: [Valgrind-users] Illegal instruction error in some versions of valgrind

[Steve E. <st...@ed...>]

On 27/01/26 8:17 pm, Paul Floyd via Valgrind-users wrote:
>
> On 27/01/2026 01:06, Steve Edmonds wrote:
>> Hi. I have just joined the group to see if I can resolve a long 
>> standing issue with valgrind on Opensuse.
>> I have been using some accounting software for many years, initially 
>> it ran fine and then at some point it started causing a segmentation 
>> fault.
>>
>> I then started using it with valgrind, successful with some versions 
>> of valgrind and not with others, when it fails I get the following 
>> before termination and core dump.
>>
>> ==199084==  Illegal opcode at address 0x453BC82
>> ==199084==    at 0x453BC82: write_vec (xcb_conn.c:262)
>>
>> Using valgrind from the latest Leap 15.6 and 16.0 repositories fails 
>> (valgrind-3.26.0-355.d_t.2.x86_64.rpm, 3.24.0-150600.3.3.1, 
>> 3.22.0-150600.1.3, 3.24.0-160000.2.2 and 3.25.1-160000.1.1) I do have 
>> the software running successfully with versions 3.25.1-350.d_t.1 (on 
>> Leap 15.6) and 3.13.0-lp150.4.61-x86_64 (on Leap 15.0 in a VM). I am 
>> trying to get to grips with what might determine a successful version 
>> of valgrind, I can no longer locate the rpm for 3.25.1-350.d_t.1 to 
>> try on Leap 16.0 and quite happy to build from source if there is 
>> some configuration in the source that will resolve this issue.
>
> Hi Steve
>
> Trying older Valgrind versions is unlikely solve the problem.
>
> What application are you trying to run under Valgrind? I just tried 
> Valgrind 3.25.1 on openSUSE LEAP 16.0 running kwrite and there were no 
> major issues.
>
> In gdb (with kwrite again) that piece of code looks like
>
> 261     n = *count;
> 262     if (n > IOV_MAX)
> 263 n = IOV_MAX;
>
> Nothing unusual in the assembler, like like it is using SSE instructions.
>
> Can you also post the op-code bytes that Valgrind fails to handle?
>
> Lastly, have you built your own copy of libxcb.so.1? If so, did you 
> use any GCC options like -march? There are a few amd64 CPU features 
> that like AVX512 that Valgrind does not support.
>
> Regards
>
> Paul
Thanks for replying Paul. I am going to have to shelve this for a few 
days as I have had a few setbacks with the DUP to Leap 16.0 and need to 
get a bit of work done.
A few things to sort out also with my legacy software as the update 
cleaned out a few files relating to sysV init used in 15.6.

Regards, Steve

Re: [Valgrind-users] Illegal instruction error in some versions of valgrind

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

On 27/01/2026 01:06, Steve Edmonds wrote:
> Hi. I have just joined the group to see if I can resolve a long 
> standing issue with valgrind on Opensuse.
> I have been using some accounting software for many years, initially 
> it ran fine and then at some point it started causing a segmentation 
> fault.
>
> I then started using it with valgrind, successful with some versions 
> of valgrind and not with others, when it fails I get the following 
> before termination and core dump.
>
> ==199084==  Illegal opcode at address 0x453BC82
> ==199084==    at 0x453BC82: write_vec (xcb_conn.c:262)
>
> Using valgrind from the latest Leap 15.6 and 16.0 repositories fails 
> (valgrind-3.26.0-355.d_t.2.x86_64.rpm, 3.24.0-150600.3.3.1, 
> 3.22.0-150600.1.3, 3.24.0-160000.2.2 and 3.25.1-160000.1.1) I do have 
> the software running successfully with versions 3.25.1-350.d_t.1 (on 
> Leap 15.6) and 3.13.0-lp150.4.61-x86_64 (on Leap 15.0 in a VM). I am 
> trying to get to grips with what might determine a successful version 
> of valgrind, I can no longer locate the rpm for 3.25.1-350.d_t.1 to 
> try on Leap 16.0 and quite happy to build from source if there is some 
> configuration in the source that will resolve this issue.

Hi Steve

Trying older Valgrind versions is unlikely solve the problem.

What application are you trying to run under Valgrind? I just tried 
Valgrind 3.25.1 on openSUSE LEAP 16.0 running kwrite and there were no 
major issues.

In gdb (with kwrite again) that piece of code looks like

261     n = *count;
262     if (n > IOV_MAX)
263 n = IOV_MAX;

Nothing unusual in the assembler, like like it is using SSE instructions.

Can you also post the op-code bytes that Valgrind fails to handle?

Lastly, have you built your own copy of libxcb.so.1? If so, did you use 
any GCC options like -march? There are a few amd64 CPU features that 
like AVX512 that Valgrind does not support.

Regards

Paul

[Valgrind-users] Illegal instruction error in some versions of valgrind

[Steve E. <st...@ed...>]

Hi. I have just joined the group to see if I can resolve a long standing 
issue with valgrind on Opensuse.
I have been using some accounting software for many years, initially it 
ran fine and then at some point it started causing a segmentation fault.

I then started using it with valgrind, successful with some versions of 
valgrind and not with others, when it fails I get the following before 
termination and core dump.

==199084==  Illegal opcode at address 0x453BC82
==199084==    at 0x453BC82: write_vec (xcb_conn.c:262)

Using valgrind from the latest Leap 15.6 and 16.0 repositories fails 
(valgrind-3.26.0-355.d_t.2.x86_64.rpm, 3.24.0-150600.3.3.1, 
3.22.0-150600.1.3, 3.24.0-160000.2.2 and 3.25.1-160000.1.1) I do have 
the software running successfully with versions 3.25.1-350.d_t.1 (on 
Leap 15.6) and 3.13.0-lp150.4.61-x86_64 (on Leap 15.0 in a VM). I am 
trying to get to grips with what might determine a successful version of 
valgrind, I can no longer locate the rpm for 3.25.1-350.d_t.1 to try on 
Leap 16.0 and quite happy to build from source if there is some 
configuration in the source that will resolve this issue. Any help much 
appreciated, Steve

Re: [Valgrind-users] problem using valgrind on x86 binary

[Mark R. <ma...@cs...>]

This was a problem that was fixed in V3.23. Our tool is based on an earlier
version. I will need to upgrade.
Mark

-----Original Message-----
From: Mark Roberts <ma...@cs...>
Sent: Sunday, January 18, 2026 4:06 PM
To: 'val...@li...'
<val...@li...>
Cc: 'Paul Floyd' <pj...@wa...>
Subject: problem using valgrind on x86 binary

I am running Ubuntu 25.10 on wsl on a X86-64 machine. As mentioned
previously, we build a program analysis tool that uses Valgrind to give us
detailed instruction execution information.  I have a test case that runs
correctly both with Valgrind and with our tool (Fjalar) when the test case
is built for X86-64. When the test case is built for X86 it still runs fine
on Valgrind but fails very early when running on FJalar.  I have attached
'--trace-flags' logs of the two cases.  No doubt we have made a mistake
somewhere, but as the failure is an unrecognized instruction while sill
symbolically executing the loader we are unsure how to proceed. Perhaps we
have corrupted this piece of memory - but it's read only, right? If anybody
has any suggestions as to how to proceed with debugging, we would be very
grateful.

-----Original Message-----
From: Paul Floyd via Valgrind-users <val...@li...>
Sent: Friday, January 16, 2026 12:55 PM
To: val...@li...
Subject: Re: [Valgrind-users] set up Valgrind for multiple targets


On 2026-01-16 21:05, Mark Roberts wrote:
> I'd like to be able to use Valgrind on both x86 and x86-64 binaries
> running on my x64-64 linux system.  I quite familiar with building and
> using Valgrind on X86-64 binaries, we use Valgrind as the framework to
> build our DynComp tool to do comparability analysis and type inference
> of C/C++ programs.  I would like to do the same for x86 binaries, but
> I am unsure of the process to setup a secondary target.
>
Hi Mark

What OS are you using?
At the moment I mainly use FreeBSD amd64, Fedora Linux amd64 and a bit of
openSUSE amd64.
For systems where I have the full 32bit subsystem installed then all I have
to do is run configure.
Autoconf should detect both amd64 and x86 and build both of them.
So really all that you need to to is to install the x86 libc. You need the
x86 C++ standard lib if you want to run the regression tests.
openSUSE has removed the x86 startup file from gcc so it can no longer build
x86 binaries (it will still run them). So in some cases you may need to
build a compiler for the platform.

Regards

Paul




_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] problem using valgrind on x86 binary

[Mark R. <ma...@cs...>]

I am running Ubuntu 25.10 on wsl on a X86-64 machine. As mentioned
previously, we build a program analysis tool that uses Valgrind to give us
detailed instruction execution information.  I have a test case that runs
correctly both with Valgrind and with our tool (Fjalar) when the test case
is built for X86-64. When the test case is built for X86 it still runs fine
on Valgrind but fails very early when running on FJalar.  I have attached
'--trace-flags' logs of the two cases.  No doubt we have made a mistake
somewhere, but as the failure is an unrecognized instruction while sill
symbolically executing the loader we are unsure how to proceed. Perhaps we
have corrupted this piece of memory - but it's read only, right? If anybody
has any suggestions as to how to proceed with debugging, we would be very
grateful.

-----Original Message-----
From: Paul Floyd via Valgrind-users <val...@li...>
Sent: Friday, January 16, 2026 12:55 PM
To: val...@li...
Subject: Re: [Valgrind-users] set up Valgrind for multiple targets


On 2026-01-16 21:05, Mark Roberts wrote:
> I'd like to be able to use Valgrind on both x86 and x86-64 binaries
> running on my x64-64 linux system.  I quite familiar with building and
> using Valgrind on X86-64 binaries, we use Valgrind as the framework to
> build our DynComp tool to do comparability analysis and type inference
> of C/C++ programs.  I would like to do the same for x86 binaries, but
> I am unsure of the process to setup a secondary target.
>
Hi Mark

What OS are you using?
At the moment I mainly use FreeBSD amd64, Fedora Linux amd64 and a bit of
openSUSE amd64.
For systems where I have the full 32bit subsystem installed then all I have
to do is run configure.
Autoconf should detect both amd64 and x86 and build both of them.
So really all that you need to to is to install the x86 libc. You need the
x86 C++ standard lib if you want to run the regression tests.
openSUSE has removed the x86 startup file from gcc so it can no longer build
x86 binaries (it will still run them). So in some cases you may need to
build a compiler for the platform.

Regards

Paul




_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] set up Valgrind for multiple targets

[Mark R. <ma...@cs...>]

I am using Ubuntu 25.10 running in a WSL2 box on win 10.



Didn't realize I needed to rebuild after installing 32bit runtime.  All is
looking much better. Except now I have to debug our tool running on 32
bits. 😊



Thanks, Mark



-----Original Message-----
From: Paul Floyd via Valgrind-users <val...@li...>
Sent: Friday, January 16, 2026 12:55 PM
To: val...@li...
Subject: Re: [Valgrind-users] set up Valgrind for multiple targets





On 2026-01-16 21:05, Mark Roberts wrote:

> I'd like to be able to use Valgrind on both x86 and x86-64 binaries

> running on my x64-64 linux system.  I quite familiar with building and

> using Valgrind on X86-64 binaries, we use Valgrind as the framework to

> build our DynComp tool to do comparability analysis and type inference

> of C/C++ programs.  I would like to do the same for x86 binaries, but

> I am unsure of the process to setup a secondary target.

>

Hi Mark



What OS are you using?



At the moment I mainly use FreeBSD amd64, Fedora Linux amd64 and a bit of
openSUSE amd64.



For systems where I have the full 32bit subsystem installed then all I have
to do is run



configure.



Autoconf should detect both amd64 and x86 and build both of them.



So really all that you need to to is to install the x86 libc. You need the
x86 C++ standard lib if you want to run the regression tests.



openSUSE has removed the x86 startup file from gcc so it can no longer
build x86 binaries (it will still run them). So in some cases you may need
to build a compiler for the platform.



Regards



Paul









_______________________________________________

Valgrind-users mailing list

Val...@li...

https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] set up Valgrind for multiple targets

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

On 2026-01-16 21:05, Mark Roberts wrote:
> I'd like to be able to use Valgrind on both x86 and x86-64 binaries running
> on my x64-64 linux system.  I quite familiar with building and using
> Valgrind on X86-64 binaries, we use Valgrind as the framework to build our
> DynComp tool to do comparability analysis and type inference of C/C++
> programs.  I would like to do the same for x86 binaries, but I am unsure of
> the process to setup a secondary target.
>
Hi Mark

What OS are you using?

At the moment I mainly use FreeBSD amd64, Fedora Linux amd64 and a bit 
of openSUSE amd64.

For systems where I have the full 32bit subsystem installed then all I 
have to do is run

configure.

Autoconf should detect both amd64 and x86 and build both of them.

So really all that you need to to is to install the x86 libc. You need 
the x86 C++ standard lib if you want to run the regression tests.

openSUSE has removed the x86 startup file from gcc so it can no longer 
build x86 binaries (it will still run them). So in some cases you may 
need to build a compiler for the platform.

Regards

Paul

[Valgrind-users] set up Valgrind for multiple targets

[Mark R. <ma...@cs...>]

I'd like to be able to use Valgrind on both x86 and x86-64 binaries running
on my x64-64 linux system.  I quite familiar with building and using
Valgrind on X86-64 binaries, we use Valgrind as the framework to build our
DynComp tool to do comparability analysis and type inference of C/C++
programs.  I would like to do the same for x86 binaries, but I am unsure of
the process to setup a secondary target.

I would be grateful for any suggestions.
Thank you
Mark Roberts

Re: [Valgrind-users] Unhandled instruction bytes: 0xD9 0xD0 (fnop)

[Mark <ma...@zb...>]

On 1/15/26 15:15, Alexandra Petlanova Hajkova wrote:

> Thank you for your contribution, this looks like a correct fix. I would suggest attaching it to one of the bugs you have mentioned.

Thanks, Alexandra, for the feedback. I have attached the proposed fix to https://bugs.kde.org/show_bug.cgi?id=126256

Mark

Re: [Valgrind-users] Unhandled instruction bytes: 0xD9 0xD0 (fnop)

[Alexandra P. H. <aha...@re...>]

On Thu, Jan 15, 2026 at 12:10 PM Mark <ma...@zb...> wrote:

> I am trying to port a legacy windows 32-bit delphi application (a 3d
> fractal image generator) to free pascal on linux. The application loads
> fractal formulas as machine code at runtime into memory for execution. The
> origin of the machine code is unclear, it may be written by hand or
> generated by unknown compilers, so I can't easily change it. When testing
> the ported application with valgrind I often encounter this message when
> the external code is loaded:
>
> vex x86->IR: unhandled instruction bytes: 0xD9 0xD0 0xE9 0xAA
> ==00:00:00:01.399 55074== valgrind: Unrecognised instruction at address
> 0x405e01a.
>
> The sequence 0xd9 0xd0 is fnop in intel x86. Checking bugzilla I found two
> related bugs:
>
>    https://bugs.kde.org/show_bug.cgi?id=126256
>    https://bugs.kde.org/show_bug.cgi?id=253446
>
> There is also a reference to fnop in the valgrind git repo in
> docs/internals/3_1_BUGSTATUS.txt (the bug number mentioned there is 125265
> but that is perhaps just a typo because it refers to a kmail bug).
>
> I can reproduce the issue within valgrind (git master@758b0f55e) with the
> following test:
>
> diff --git a/none/tests/x86/insn_fpu.def b/none/tests/x86/insn_fpu.def
> index 590f5844c..f5a8d61c4 100644
> --- a/none/tests/x86/insn_fpu.def
> +++ b/none/tests/x86/insn_fpu.def
> @@ -1,3 +1,4 @@
> +fnop
>   fabs st0.ps[1234.5678] : => st0.ps[1234.5678]
>   fabs st0.ps[-1234.5678] : => st0.ps[1234.5678]
>   fabs st0.pd[12345678.87654321] : => st0.pd[12345678.87654321]
> diff --git a/none/tests/x86/insn_fpu.stdout.exp
> b/none/tests/x86/insn_fpu.stdout.exp
> index 67128c13b..f5f4a161f 100644
> --- a/none/tests/x86/insn_fpu.stdout.exp
> +++ b/none/tests/x86/insn_fpu.stdout.exp
> @@ -1,3 +1,4 @@
> +fnop_1 ... ok
>   fabs_1 ... ok
>   fabs_2 ... ok
>   fabs_3 ... ok
>
> This patch fixes the issue and lets the test pass (both in valgrind and my
> application):
>
> diff --git a/VEX/priv/guest_x86_toIR.c b/VEX/priv/guest_x86_toIR.c
> index bd4ccd54b..710905ad1 100644
> --- a/VEX/priv/guest_x86_toIR.c
> +++ b/VEX/priv/guest_x86_toIR.c
> @@ -4204,6 +4204,10 @@ UInt dis_FPU ( Bool* decode_ok, UChar sorb, Int
> delta )
>                  put_ST_UNCHECKED(r_src, mkexpr(t1));
>                  break;
>
> +            case 0xD0: /* FNOP */
> +               DIP("fnop\n");
> +               break;
> +
>               case 0xE0: /* FCHS */
>                  DIP("fchs\n");
>                  put_ST_UNCHECKED(0, unop(Iop_NegF64, get_ST(0)));
>
> The complete patch is included at the end of this mail including the same
> fix and regression test also for amd64 and a fix for the documentation
> typo. Would that be a proper solution or am I missing something?
>
> Thanks,
> Mark
>
> Hi Mark,


Thank you for your contribution, this looks like a correct fix. I would
suggest attaching it to one of the bugs you have mentioned.

Thank you,
Alexandra

[Valgrind-users] Unhandled instruction bytes: 0xD9 0xD0 (fnop)

[Mark <ma...@zb...>]

I am trying to port a legacy windows 32-bit delphi application (a 3d fractal image generator) to free pascal on linux. The application loads fractal formulas as machine code at runtime into memory for execution. The origin of the machine code is unclear, it may be written by hand or generated by unknown compilers, so I can't easily change it. When testing the ported application with valgrind I often encounter this message when the external code is loaded:

vex x86->IR: unhandled instruction bytes: 0xD9 0xD0 0xE9 0xAA
==00:00:00:01.399 55074== valgrind: Unrecognised instruction at address 0x405e01a.

The sequence 0xd9 0xd0 is fnop in intel x86. Checking bugzilla I found two related bugs:

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

There is also a reference to fnop in the valgrind git repo in docs/internals/3_1_BUGSTATUS.txt (the bug number mentioned there is 125265 but that is perhaps just a typo because it refers to a kmail bug).

I can reproduce the issue within valgrind (git master@758b0f55e) with the following test:

diff --git a/none/tests/x86/insn_fpu.def b/none/tests/x86/insn_fpu.def
index 590f5844c..f5a8d61c4 100644
--- a/none/tests/x86/insn_fpu.def
+++ b/none/tests/x86/insn_fpu.def
@@ -1,3 +1,4 @@
+fnop
  fabs st0.ps[1234.5678] : => st0.ps[1234.5678]
  fabs st0.ps[-1234.5678] : => st0.ps[1234.5678]
  fabs st0.pd[12345678.87654321] : => st0.pd[12345678.87654321]
diff --git a/none/tests/x86/insn_fpu.stdout.exp b/none/tests/x86/insn_fpu.stdout.exp
index 67128c13b..f5f4a161f 100644
--- a/none/tests/x86/insn_fpu.stdout.exp
+++ b/none/tests/x86/insn_fpu.stdout.exp
@@ -1,3 +1,4 @@
+fnop_1 ... ok
  fabs_1 ... ok
  fabs_2 ... ok
  fabs_3 ... ok

This patch fixes the issue and lets the test pass (both in valgrind and my application):

diff --git a/VEX/priv/guest_x86_toIR.c b/VEX/priv/guest_x86_toIR.c
index bd4ccd54b..710905ad1 100644
--- a/VEX/priv/guest_x86_toIR.c
+++ b/VEX/priv/guest_x86_toIR.c
@@ -4204,6 +4204,10 @@ UInt dis_FPU ( Bool* decode_ok, UChar sorb, Int delta )
                 put_ST_UNCHECKED(r_src, mkexpr(t1));
                 break;

+            case 0xD0: /* FNOP */
+               DIP("fnop\n");
+               break;
+
              case 0xE0: /* FCHS */
                 DIP("fchs\n");
                 put_ST_UNCHECKED(0, unop(Iop_NegF64, get_ST(0)));

The complete patch is included at the end of this mail including the same fix and regression test also for amd64 and a fix for the documentation typo. Would that be a proper solution or am I missing something?

Thanks,
Mark

diff --git a/VEX/priv/guest_amd64_toIR.c b/VEX/priv/guest_amd64_toIR.c
index 34ebcbdf9..0319578f2 100644
--- a/VEX/priv/guest_amd64_toIR.c
+++ b/VEX/priv/guest_amd64_toIR.c
@@ -5967,6 +5967,10 @@ ULong dis_FPU ( /*OUT*/Bool* decode_ok,
                 put_ST_UNCHECKED(r_src, mkexpr(t1));
                 break;

+            case 0xD0: /* FNOP */
+               DIP("fnop\n");
+               break;
+
              case 0xE0: /* FCHS */
                 DIP("fchs\n");
                 put_ST_UNCHECKED(0, unop(Iop_NegF64, get_ST(0)));
diff --git a/VEX/priv/guest_x86_toIR.c b/VEX/priv/guest_x86_toIR.c
index bd4ccd54b..710905ad1 100644
--- a/VEX/priv/guest_x86_toIR.c
+++ b/VEX/priv/guest_x86_toIR.c
@@ -4204,6 +4204,10 @@ UInt dis_FPU ( Bool* decode_ok, UChar sorb, Int delta )
                 put_ST_UNCHECKED(r_src, mkexpr(t1));
                 break;

+            case 0xD0: /* FNOP */
+               DIP("fnop\n");
+               break;
+
              case 0xE0: /* FCHS */
                 DIP("fchs\n");
                 put_ST_UNCHECKED(0, unop(Iop_NegF64, get_ST(0)));
diff --git a/docs/internals/3_1_BUGSTATUS.txt b/docs/internals/3_1_BUGSTATUS.txt
index 6add0ccac..4134c3cb9 100644
--- a/docs/internals/3_1_BUGSTATUS.txt
+++ b/docs/internals/3_1_BUGSTATUS.txt
@@ -54,7 +54,7 @@ v5877     fixed   126217  increase # threads
  v5880     fixed   n-i-bz  vectorise copy_address_range_state
                    n-i-bz  mpicc -fpic bug (Goedeken Richard, inbox)
  vx1611    fixed   126243  vex x86->IR: popw mem
-          low     125265  vex x86->IR: 0xD9 0xD0 (fnop)
+          low     126256  vex x86->IR: 0xD9 0xD0 (fnop)
            low     126257  vex x86->IR: 0xF2 0x0F 0xF0 0x40 (lddqu) (sse3)
            low     126258  vex x86->IR: 0xDF 0x4D (fisttp) (sse3)
                    126384  rdpmc
diff --git a/none/tests/amd64/insn_fpu.def b/none/tests/amd64/insn_fpu.def
index 525fd1b1b..219247478 100644
--- a/none/tests/amd64/insn_fpu.def
+++ b/none/tests/amd64/insn_fpu.def
@@ -1,3 +1,4 @@
+fnop
  fabs st0.ps[1234.5678] : => st0.ps[1234.5678]
  fabs st0.ps[-1234.5678] : => st0.ps[1234.5678]
  fabs st0.pd[12345678.87654321] : => st0.pd[12345678.87654321]
diff --git a/none/tests/amd64/insn_fpu.stdout.exp b/none/tests/amd64/insn_fpu.stdout.exp
index 67128c13b..f5f4a161f 100644
--- a/none/tests/amd64/insn_fpu.stdout.exp
+++ b/none/tests/amd64/insn_fpu.stdout.exp
@@ -1,3 +1,4 @@
+fnop_1 ... ok
  fabs_1 ... ok
  fabs_2 ... ok
  fabs_3 ... ok
diff --git a/none/tests/x86/insn_fpu.def b/none/tests/x86/insn_fpu.def
index 590f5844c..f5a8d61c4 100644
--- a/none/tests/x86/insn_fpu.def
+++ b/none/tests/x86/insn_fpu.def
@@ -1,3 +1,4 @@
+fnop
  fabs st0.ps[1234.5678] : => st0.ps[1234.5678]
  fabs st0.ps[-1234.5678] : => st0.ps[1234.5678]
  fabs st0.pd[12345678.87654321] : => st0.pd[12345678.87654321]
diff --git a/none/tests/x86/insn_fpu.stdout.exp b/none/tests/x86/insn_fpu.stdout.exp
index 67128c13b..f5f4a161f 100644
--- a/none/tests/x86/insn_fpu.stdout.exp
+++ b/none/tests/x86/insn_fpu.stdout.exp
@@ -1,3 +1,4 @@
+fnop_1 ... ok
  fabs_1 ... ok
  fabs_2 ... ok
  fabs_3 ... ok