valgrind-users — General discussion list for Valgrind users

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.

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

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

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

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.

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

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

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

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

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

Hi,

On Tue, 2025-04-22 at 18:37 +0200, Mark Wielaard wrote:
> On Tue, 2025-04-22 at 00:29 +0200, Florian Krohm wrote:
> > On 18.04.25 15:53, Mark Wielaard wrote:
> > > 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
> > 
> > none/tests/bug290061.c
> > bug290061.c:1:13: warning: ‘meh’ defined but not used [-Wunused-variable]
> > 
> > I guess we want a clean build.. Making 'meh' volatile removes the warning.

Sorry, missed that Paul fixed the issue already. That is why I couldn't
replicate :)

Cheers,

Mark

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

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

Hi Florian,

On Tue, 2025-04-22 at 00:29 +0200, Florian Krohm wrote:
> On 18.04.25 15:53, Mark Wielaard wrote:
> > 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
> 
> none/tests/bug290061.c
> bug290061.c:1:13: warning: ‘meh’ defined but not used [-Wunused-variable]
> 
> I guess we want a clean build.. Making 'meh' volatile removes the warning.

I am not seeing that locally. meh is used, although maybe the compiler
is smart enough to notice only meh[0] is actually used. What compiler
(version) and flags are you using?

> These files are missing:
> - auxprogs/ltp-tester.sh
> - auxprogs/ltp-excludes.txt
> - auxprogs/ltp-error-patterns.txt

Oops. Added them to EXTRA_DIST so they are in the tar ball for RC2.

> After adding them make ltpchecks took some 45 minutes on my z15 with about 46 
> failing tests. Not too bad..

I assume most of the failures are missing syscall wrappers? On my
x86_64 setup I got 66 FAILs, full log here:
https://bugsfiles.kde.org/attachment.cgi?id=180366

Cheers,

Mark

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

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

On 4/20/25 04:13, Sean McBride wrote:
> On 19 Apr 2025, at 12:48, Paul Floyd via Valgrind-users wrote:
>
>> I'll give macOS a go shortly.
> macOS?  It hasn't been supported in years, unless I missed some exciting news?

macOS is lagging far behind. In the last 6 months I made 4 changes for 
Darwin

- added the mkdirat syscall wrapper

- fixes for macho reading (to be compatible with ELF)

- one regression test fix

That's only for macOS 10.13 which is very old and probably little used. 
The most recent macOS has moved to arm64.

Louis Brunner has done a lot of work on his GitHub fork 
https://github.com/LouisBrunner/valgrind-macos

Maybe after I've finished getting Illumos back up to speed I'll have a 
go at merging more of that code.


A+

Paul

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

[Sean M. <se...@ro...>]

On 19 Apr 2025, at 12:48, Paul Floyd via Valgrind-users wrote:

> I'll give macOS a go shortly.

macOS?  It hasn't been supported in years, unless I missed some exciting news?

Sean

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

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

On 19-04-25 16:48, Paul Floyd via Valgrind-users wrote:
> 
> On 4/18/25 15:53, Mark Wielaard wrote:
>> Slightly later than originally planned, but the RC1 is finally out!
> 
> Hi Mark
> 
> There was one small regtest issue on FreeBSD (a script missing from 
> dist_noinst_SCRIPTS in none/tests/freebsd/Makefile.am). It's not a 
> blocking issue and it should now be fixed.
> 
> Illumos is also OK.
> 
> I'll give macOS a go shortly.

It builds and sometimes works:

== 705 tests, 194 stderr failures, 11 stdout failures, 0 stderrB 
failures, 0 stdoutB failures, 4 post failures ==

A+
Paul