valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Valgrind-3.24.0 is available

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

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

See the release notes below for details of changes.

Our thanks to all those who contribute to Valgrind's development.  This
release represents a great deal of time, energy and effort on the part
of many people.

Happy and productive debugging and profiling,

-- The Valgrind Developers

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Release 3.24.0 (31 Oct 2024)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

* Bad file descriptor usage now generates a real error with
  --track-fds=yes that is suppressible and shows up in the xml output
  with full execution backtrace. The warnings shown without using the
  option are deprecated and will be removed in a future valgrind
  version.

* Ada name demangling is now supported in error messages.

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

* S390X added support for the DFLTCC instruction provided by the
  deflate-conversion facility (z15/arch13).

* S390X added support for the instructions provided by the MSA facility
  and MSA extensions 1-9.

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

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

202770  open fd at exit --log-socket=127.0.0.1:1500 with --track-fds=yes
276780  An instruction in fftw (Fast Fourier Transform) is unhandled by
        valgrind: vex x86->IR: unhandled instruction bytes:
        0x66 0xF 0x3A 0x2
311655  --log-file=FILE leads to apparent fd leak
317127  Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch
337388  fcntl works on Valgrind's own file descriptors
377966  arm64 unhandled instruction dc zva392146  aarch64: unhandled
        instruction 0xD5380001 (MRS rT, midr_el1)
391148  Unhandled AVX instruction vmovq %xmm9,%xmm1
392146  aarch64: unhandled instruction 0xD5380001 (MRS rT, midr_el1)
412377  SIGILL on cache flushes on arm64
417572  vex amd64->IR: unhandled instruction bytes: 0xC5 0x79 0xD6 0xED 0xC5
440180  s390x: Failed assertion in disassembler
444781  MIPS: wrong syscall numbers used
447989  Support Armv8.2 SHA-512 instructions
445235  Java/Ada/D demangling is probably broken
453044  gbserver_tests failures in aarch64
479661  Valgrind leaks file descriptors
486180  [Valgrind][MIPS] 'VexGuestArchState' has no member named
        'guest_IP_AT_SYSCALL'
486293  memccpy false positives
486569  linux inotify_init syscall wrapper missing POST entry in syscall_table
487439  SIGILL in JDK11, JDK17
487993  Alignment error when using Eigen with Valgrind and -m32
488026  Use of `sizeof` instead of `strlen
488379  --track-fds=yes errors that cannot be suppressed with --xml-file=
488441  Add tests for --track-fds=yes --xml=yes and fd suppression tests
489040  massif trace change to show the location increasing the stack
489088  Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5
489338  arm64: Instruction fcvtas should round 322.5 to 323, but result is 322.
489676  vgdb handle EINTR and EAGAIN more consistently
490651  Stop using -flto-partition=one
491394  (vgModuleLocal_addDiCfSI): Assertion 'di->fsm.have_rx_map &&
        di->fsm.rw_map_count' failed
492210  False positive on x86/amd64 with ZF taken directly from addition
492214  statx(fd, NULL, AT_EMPTY_PATH) is supported since Linux 6.11
        but not supported in valgrind
492422  Please support DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD
492663  Valgrind ignores debug info for some binaries
493418  Add bad fd usage errors for --track-fds in ML_(fd_allowed)
493454  Missing FUSE_COMPATIBLE_MAY_BLOCK markers
493507  direct readlink syscall from PRE handler is incompatible with
        FUSE_COMPATIBLE_MAY_BLOCK
493959  s390x: Fix regtest failure for none/tests/s390x/op00
493970  s390x: Store/restore FPC upon helper call causes slowdown
494252  s390x: incorrect disassembly for LOCHI and friends
494960  Fixes and tweaks for gsl19test
495278  PowerPC instruction dcbf should allow the L field values of 4, 6 on
        ISA 3.0 and earlier, just ignore the value
495469  aligned_alloc and posix_memalign missing MALLOC_TRACE with returned
        pointer
495470  s390x: 3.24.0.RC1 missing file and regtest failure
n-i-bz  Improve messages for sigaltstack errors, use specific
        stack_t member names

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.24.0.RC1: 27 Oct 2024)

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

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

Mark:

PowerPC testing on Power 8, I am seeing 4 additional stderr failures 
versus Valgrind 3.23.0.RC2

  == 749 tests, 7 stderr failures, 0 stdout failures, 13 stderrB 
failures, 0 stdoutB failures, 0 post failures ==
gdbserver_tests/hginfo (stderrB)
gdbserver_tests/mcblocklistsearch (stderrB)
gdbserver_tests/mcbreak (stderrB)
gdbserver_tests/mcclean_after_fork (stderrB)
gdbserver_tests/mcinfcallWSRU (stderrB)
gdbserver_tests/mcleak (stderrB)
gdbserver_tests/mcmain_pic (stderrB)
gdbserver_tests/mcvabits (stderrB)
gdbserver_tests/mssnapshot (stderrB)
gdbserver_tests/nlgone_abrt (stderrB)
gdbserver_tests/nlgone_exit (stderrB)
gdbserver_tests/nlgone_return (stderrB)
gdbserver_tests/nlpasssigalrm (stderrB)
memcheck/tests/leak_cpp_interior (stderr)
memcheck/tests/linux/rfcomm (stderr)
memcheck/tests/linux/sys-execveat (stderr)
none/tests/fdleak_cmsg_supp              (stderr)          New for 
Valgrind-3.24.0.RC1
none/tests/fdleak_cmsg_xml               (stderr)             New for 
Valgrind-3.24.0.RC1
none/tests/fdleak_ipv4_xml               (stderr)               New for 
Valgrind-3.24.0.RC1
none/tests/socket_close_xml              (stderr)             New for 
Valgrind-3.24.0.RC1



PowerPC testing on Power 9, I am seeing 4 additional stderr failures 
versus Valgrind 3.23.0.RC2

  == 767 tests, 7 stderr failures, 0 stdout failures, 13 stderrB 
failures, 0 stdoutB failures, 0 post failures ==
gdbserver_tests/hginfo                   (stderrB)
gdbserver_tests/mcblocklistsearch        (stderrB)
gdbserver_tests/mcbreak                  (stderrB)
gdbserver_tests/mcclean_after_fork       (stderrB)
gdbserver_tests/mcinfcallWSRU            (stderrB)
gdbserver_tests/mcleak                   (stderr)
gdbserver_tests/mcleak                   (stderrB)
gdbserver_tests/mcmain_pic               (stderrB)
gdbserver_tests/mcvabits                 (stderrB)
gdbserver_tests/mssnapshot               (stderrB)
gdbserver_tests/nlgone_abrt              (stderrB)
gdbserver_tests/nlgone_exit              (stderrB)
gdbserver_tests/nlgone_return            (stderrB)
gdbserver_tests/nlpasssigalrm            (stderrB)
memcheck/tests/leak-delta                (stderr)
memcheck/tests/linux/rfcomm              (stderr)
none/tests/fdleak_cmsg_supp              (stderr)        New for 
Valgrind-3.24.0.RC1
none/tests/fdleak_cmsg_xml               (stderr)        New for 
Valgrind-3.24.0.RC1
none/tests/fdleak_ipv4_xml               (stderr)        New for 
Valgrind-3.24.0.RC1
none/tests/socket_close_xml              (stderr)        New for 
Valgrind-3.24.0.RC1



PowerPC testing on Power 10, I am seeing 4 additional stderr failures 
versus Valgrind 3.23.0.RC2

== 753 tests, 5 stderr failures, 0 stdout failures, 0 stderrB failures, 
0 stdoutB failures, 0 post failures ==
memcheck/tests/linux/rfcomm              (stderr)
none/tests/fdleak_cmsg_supp (stderr)                      New for 
Valgrind-3.24.0.RC1
none/tests/fdleak_cmsg_xml               (stderr)                      
New for Valgrind-3.24.0.RC1
none/tests/fdleak_ipv4_xml               (stderr)                      
New for Valgrind-3.24.0.RC1
none/tests/socket_close_xml              (stderr)                      
New for Valgrind-3.24.0.RC1

I am not sure what is going on with these tests.  I have not yet been 
able to dig into them.
                                               Carl

On 10/27/24 4:58 PM, Mark Wielaard wrote:
> There are still some pending patches, but lets do an RC1 for some
> wider testing.
>
> An RC1 tarball for 3.24.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.24.0.RC1.tar.bz2
> (md5sum = a11f33c94dcb0f545a27464934b6fef8)
> (sha1sum = b87105b23d3b6d0e212d5729235d0d8225ff8851)
> https://sourceware.org/pub/valgrind/valgrind-3.24.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
>
> If nothing critical emerges a final release will happen on Thursday 31
> October.
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

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

There are still some pending patches, but lets do an RC1 for some
wider testing.

An RC1 tarball for 3.24.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.24.0.RC1.tar.bz2
(md5sum = a11f33c94dcb0f545a27464934b6fef8)
(sha1sum = b87105b23d3b6d0e212d5729235d0d8225ff8851)
https://sourceware.org/pub/valgrind/valgrind-3.24.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

If nothing critical emerges a final release will happen on Thursday 31
October.

Re: [Valgrind-users] Uninitialized variable detection in Fortran

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

On 26-10-24 13:36, Daniel Feenberg wrote:
> 

> 
> This is very disappointing. Such moves may be frequent in other 
> languages, but I don't see it happening to much in my Fortran 95 code. I 
> suppose if subroutine arguments are copy-in/copy-out, that would be a 
> source of spurious messages, as could code in libgfortran,but Valgrind 
> typically has the source and could drop those messages.
> 
> I did eventually locate the problem in my code, by adding a large number 
> of write statements scattered thoughout the code, and noting the 
> earliest one to trigger Valgrind.

I think that you grossly underestimate how much copying of uninitialized 
memory goes on.

Any data structure that has a hole or padding thjat gets copied means 
there is an uninitialized read. Also fields that are intentionally 
unused, which is quite common with large union based data structures.

This might be viable with a client request that only turns on the 
instrumentation for a limited part of the code.

Also note that memory sanitizer also does the same thing as memcheck.

A+
Paul

Re: [Valgrind-users] Uninitialized variable detection in Fortran

[Daniel F. <fee...@nb...>]

On Fri, 25 Oct 2024, Paul Floyd via Valgrind-users wrote:

>
>
> On 24-10-24 14:33, Daniel Feenberg via Valgrind-users wrote:

...

>>  origins" would do that. Is there an option or other way to ask Valgrind to
>>  be a little stricter, and flag the use of an unidentified variable in an
>>  assignment, not just in a condition?
>
> Uninitialized read errors are not triggered simply by reading uninitialized 
> memory. There are many cases where uninitialized memory gets copied in a 
> harmless manner. That would be overwhelming. Instead we only trigger errors

This is very disappointing. Such moves may be frequent in other languages, 
but I don't see it happening to much in my Fortran 95 code. I suppose if 
subroutine arguments are copy-in/copy-out, that would be a source of 
spurious messages, as could code in libgfortran,but Valgrind typically has 
the source and could drop those messages.

I did eventually locate the problem in my code, by adding a large number 
of write statements scattered thoughout the code, and noting the earliest 
one to trigger Valgrind.

Daniel Feenberg

Re: [Valgrind-users] Uninitialized variable detection in Fortran

[John R. <jr...@bi...>]

On 10/24/24, Daniel Feenberg via Valgrind-users wrote:
> Is there an option or other way to ask 
> Valgrind to be a little stricter, and flag the use of an unidentified 
> variable in an assignment, not just in a condition?

No.  You (and many other new users) have stumbled onto *the* colossal 
deficiency of valgrind.  Namely: despite the supreme importance of
the *OPTION* to request that valgrind behave this way, valgrind cannot.
"If a tree falls in the forest but there is no one to hear it fall,
then does it make a sound?"  Memcheck says, "No, there is no sound."
Or perhaps Memcheck would say, "There are so many trees which fall
that very probably you will give up trying to identify the one that
matters to you."

Your best bet is to find a compiler option which generates code
to check for any use of an uninit variable, and a runtime support
library that is compiled with such checking.  For the sake of
efficiency, then such a check must be heuristic, but in practice
it can be very good.  In gcc or clang for C or C++, then the
compiler option   -fsanitize=undefined   (or related) can be
effective in many cases.

Because you are working in Fortran, then having the compiler and
runtime system initialize everything to the bit pattern for some
flavor of denorm or NaN (and check for it!) might work, even
for integer variables.  A 32-bit pattern flavored like
    (0xFFF8 << 16) | (0xFFFF & (address >> 3)) ,
repeated to fill all otherwise-uninit space, comes to mind.
[Some 50+ years ago the Michigan Terminal System for IBM
System 360 model 67 initialized all bytes to 0x80 (or 0x81),
and this was quite helpful in identifying uninits.]

Then there is the problem of uninit local (on-stack) variables.
The gcc option  -mfentry  generates extra code to call a subroutine
immediately upon entry to every function, and with a little hacking
it is possible to identify the sizeof the local frame, then act.
Unfortunately, zeroing the entire local stack frame (or setting
the bytes to another known value) immediately upon allocation
tends to be very expensive: a factor of 2X, 3X, or more
in total run time.

-- 

Re: [Valgrind-users] Uninitialized variable detection in Fortran

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

On 24-10-24 14:33, Daniel Feenberg via Valgrind-users wrote:
> 
> I am a bit inexperienced with Valgrind which reports an uninitialized 
> variable in my 34,000 line program. But the message comes from a branch 
> deep in libgfortran. After some experimentation, I created the following 
> example program which demonstrates my difficulty:
> 
> cat -n test.for
>       1        program test
>       2        integer i,j
>       3        j=i+1
>       4        write(*,*) j
>       5        stop
>       6        end
> 
> I compile and run with:
> 
>     gfortran -g stuff.for
>     valgrind --track-origins=yes ./a.out
> 
> and get a great deal of output pointing to line 4. But the first use of 
> the uninitialized value is in line 3. In this case the error is obvious, 
> but IRL I haven't been able to identify the source. I thought "track- 
> origins" would do that. Is there an option or other way to ask Valgrind 
> to be a little stricter, and flag the use of an unidentified variable in 
> an assignment, not just in a condition?

--track-origins=yes tells memcheck to record the origins of 
uninitilalized memory.

It has done that and added

==4095841==  Uninitialised value was created by a stack allocation
==4095841==    at 0x401176: MAIN__ (test.for:1)

With all errors Valgrind will also read debuginfo if available to give 
you the source and line and when possible the name of the variable. In 
this case it hasn't determined the name of the variable - I don't know why.

Uninitialized read errors are not triggered simply by reading 
uninitialized memory. There are many cases where uninitialized memory 
gets copied in a harmless manner. That would be overwhelming. Instead we 
only trigger errors when the uninitialized memory affects the observable 
behaviour of the test exe. Hence "Conditional jump or move depends on 
uninitialised value(s)". So you have to do some digging to search for 
the place in the code where the variable should have been initialized.

A+
Paul

[Valgrind-users] Uninitialized variable detection in Fortran

[Daniel F. <fee...@nb...>]

I am a bit inexperienced with Valgrind which reports an uninitialized 
variable in my 34,000 line program. But the message comes from a branch 
deep in libgfortran. After some experimentation, I created the following 
example program which demonstrates my difficulty:

cat -n test.for
      1        program test
      2        integer i,j
      3        j=i+1
      4        write(*,*) j
      5        stop
      6        end

I compile and run with:

    gfortran -g stuff.for
    valgrind --track-origins=yes ./a.out

and get a great deal of output pointing to line 4. But the first use of 
the uninitialized value is in line 3. In this case the error is obvious, 
but IRL I haven't been able to identify the source. I thought 
"track-origins" would do that. Is there an option or other way to ask 
Valgrind to be a little stricter, and flag the use of an unidentified 
variable in an assignment, not just in a condition?

Here is the output with --exit-on-first-error=yes, otherwise there is an 
avalanch of text:

==4095841== Memcheck, a memory error detector
==4095841== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==4095841== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==4095841== Command: ./a.out
==4095841==
==4095841== Conditional jump or move depends on uninitialised value(s)
==4095841==    at 0x4AD2B8E: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==4095841==    by 0x4AD6C6B: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==4095841==    by 0x4AD7C66: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==4095841==    by 0x4011DC: MAIN__ (test.for:4)
==4095841==    by 0x401233: main (test.for:6)
==4095841==  Uninitialised value was created by a stack allocation
==4095841==    at 0x401176: MAIN__ (test.for:1)
==4095841==
==4095841==
==4095841== Exit program on first error (--exit-on-first-error=yes)

Thank you and any help much appreciated.

Daniel Feenberg

[Valgrind-users] Missmatch between Ir reported and instruction observed by single stepping

[Pepper G. <he...@pe...>]

Hi,

I'm having an issue with callgrind, and unfortunately I didn't find any
further information in the docs:
The instruction count is not what I expect and differs from single stepping
the binary.

I'm on x86_64-linux-gnu

I created a simple hello world example:

global _start

section .text

_start:
mov rax, 1 ; write(
mov rdi, 1 ; STDOUT_FILENO,
mov rsi, msg ; "Hello, world!\n",
mov rdx, msglen ; sizeof("Hello, world!\n")
syscall ; );

mov rax, 60 ; exit(
mov rdi, 0 ; EXIT_SUCCESS
syscall ; );

section .rodata
msg: db "Hello, world!", 10
msglen: equ $ - msg


Which has 8 instructions:

$ objdump -d hello

hello: file format elf64-x86-64


Disassembly of section .text:

0000000000401000 <_start>:
401000: b8 01 00 00 00 mov $0x1,%eax
401005: bf 01 00 00 00 mov $0x1,%edi
40100a: 48 be 00 20 40 00 00 movabs $0x402000,%rsi
401011: 00 00 00
401014: ba 0e 00 00 00 mov $0xe,%edx
401019: 0f 05 syscall
40101b: b8 3c 00 00 00 mov $0x3c,%eax
401020: bf 00 00 00 00 mov $0x0,%edi
401025: 0f 05 syscall

Running "valgrind --tool=callgrind ./hello" gives me only 5 instructions:

Hello, world!
==443229==
==443229== Events : Ir
==443229== Collected : 5
==443229==
==443229== I refs: 5

When I create a dump "valgrind --tool=callgrind --dump-instr=yes
--simulate-cache=yes --collect-jumps=yes ./hello"
and check the machie code out using KCachegrind:

#   Ir     Hex     Assembly Instructions     Source Position
40 1000  █  20.00    b8 01 00 00 00     mov $0x1, %eax     (unknown)
40 1005  █  20.00    bf 01 00 00 00     mov $0x1, %edi     (unknown)
40 100A  █  20.00    48 be 00 20 40 00 00   movabs $0x402000, %rsi
 (unknown)
40 1011    20.00    00 00 00
40 1014  █  20.00    ba 0e 00 00 00     mov $0xe, %edx     (unknown)
40 1019  █  20.00    0f 05     syscall     (unknown)
40 101B      b8 3c 00 00 00     mov $0x3c, %eax
40 1020      bf 00 00 00 00     mov $0x0, %edi

So it seems it doesn't capture the last syscall and doesn't count the last
two mov instructions.

I also checked with c files:

#include <stdio.h>

int main()
{
printf("Hello, world!\n");
return 0;
}

where valgrind gives me 139,482:

Hello, world!
==444986==
==444986== Events : Ir
==444986== Collected : 139482
==444986==
==444986== I refs: 139,482

whilst when I use fork, execv,

ptrace(PTRACE_TRACEME, 0, 0, 0)
ptrace(PTRACE_SINGLESTEP, pid, 0, 0)

to single step the binary, and count the steps, I get 126,042.


Am I missing something, or is callgrind counting something else than steps?
How can I make these numbers line up?

KR
Pepper

[Valgrind-users] Fwd: Any plans to support MacOSX 14.6?

[Georgi K. <Ge...@ko...>]

Hi,

Any plans to support that OS version? I've tried and I couldn't compile it:
I get an error it's not supported. Both the releases and the git trunk.

Best Regards,
Georgi K

Re: [Valgrind-users] Facing Issues with 32 bit Legacy Apps on ARM64 bit

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

On 10-09-24 06:59, Tech info wrote:
> We are debugging memory leaks in our legacy 32-bit multithreaded 
> applications on ARM64-bit processors, but we're facing performance 
> issues with Valgrind:
> 
>     *Application Crash*: After 9-10 minutes, the application crashes,
>     and |top commands|showsno activity for particularlegacy app.
> 

We need much more information.

Can you use Valgrind and vgdb to see where it is hanging?

I don't think that anyone is actively working on the 32bit arm port at 
the moment so unless there is an easy fix you might be on your own.

A+
Paul

[Valgrind-users] Facing Issues with 32 bit Legacy Apps on ARM64 bit

[Tech i. <tec...@gm...>]

We are debugging memory leaks in our legacy 32-bit multithreaded
applications on ARM64-bit processors, but we're facing performance issues
with Valgrind:

*Application Crash*: After 9-10 minutes, the application crashes, and top
commands shows no activity for particular legacy app.


Thanks for your help.

Re: [Valgrind-users] Subject: Valgrind Performance Issues with Legacy Apps on ARM64

[Tech i. <tec...@gm...>]

Dear Valgrind Support Team,

We are debugging memory leaks in our legacy 32-bit multithreaded
applications on ARM64-bit processors, but we're facing performance issues
with Valgrind:

   - *High CPU Usage*: Valgrind causes the application to use 100% CPU,
   disrupting other system processes.
   - *Application Crash*: After 9-10 minutes, the application crashes, and
   top shows no activity.
   - *No Improvement with Nice Value*: Adjusting the nice value to 10 did
   not alleviate the issue.
    We seek advice on optimizing Valgrind's performance or alternative
   debugging methods under these conditions.

Thank you for your help.

On Mon, Sep 9, 2024 at 9:53 AM Tech info <tec...@gm...> wrote:

>
> Dear Valgrind Support Team,
>
> We are debugging memory leaks in our legacy 32-bit multithreaded
> applications on ARM64-bit processors, but we're facing performance issues
> with Valgrind:
>
>    - *High CPU Usage*: Valgrind causes the application to use 100% CPU,
>    disrupting other system processes.
>    - *Application Crash*: After 9-10 minutes, the application crashes,
>    and top shows no activity.
>    - *No Improvement with Nice Value*: Adjusting the nice value to 10 did
>    not alleviate the issue.
>
> Attached are snapshots of the system’s behavior. We seek advice on
> optimizing Valgrind's performance or alternative debugging methods under
> these conditions.
>
> Thank you for your help.
>

Re: [Valgrind-users] Query regarding Valgrind mailer list

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

> On 5 Sep 2024, at 11:18, Isharat Mahmood <ish...@gm...> wrote:
> 
> Dear Team,
> 
> We have a query regarding Valgrind working model.
> Is it the right mailer list to ask?



If it is a Valgrind User question then this is the right list.

Otherwise there is a mailing list for Valgrind developers.

A+
Paul

[Valgrind-users] Query regarding Valgrind mailer list

[Isharat M. <ish...@gm...>]

Dear Team,

We have a query regarding Valgrind working model.
Is it the right mailer list to ask?


Thanks,
Md Isharat

Re: [Valgrind-users] Simple list of functions ever called

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

On 06-06-24 15:43, Byron Hawkins wrote:
> For the purposes of studying dead-code elimination in LLVM, I'd like to 
> generate a simple list of all the functions that are ever called by the 
> target program. There's no need for any timing or frequency reports or 
> backtraces or any other details. So far, the best solution I can find is 
> to filter callgrind output like this:
> 
>      grep -E "^c?fn" callgrind/output.raw | cut -d " " -f 2- | grep -Ev 
> "^0x|^c?fn"
> 
> It doesn't seem highly reliable, since I'm just picking out entries by 
> sort of guessing, then checking the results with gdb (setting a 
> breakpoint on every symbol not encountered by callgrind). All target 
> programs are trivial unit tests with rigid, deterministic behavior, but 
> it would still be nicer to have a more formally defined approach for 
> extracting a precise set of function symbols for which invocation was 
> observed during the execution. Thanks in advance for any suggestions.

There are various ways to get the function names. I usually use a train 
of commands like

awk '/^fn=.* .*/{print $2}' callgrind.out.3727 | sort | uniq -c | sort -n

(only printing the first field with the fn name from awk so not getting 
the full arg list).

A+
Paul

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

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

On Sat, 2024-07-20 at 10:41 -0700, Tsiang Elaine Reisler wrote:
> > 
> I agree there is no interaction in how I am using valgrind (see last
> post), but not knowing this before prompted me to ask the question on
> this list. I did not use --vgd-stop-at or setup --multi mode of
> interacting with gdbserver via gdb. Nevertheless, 'target remote |
> vgdb' is equivalent to attaching to the process in gdb, allowing full
> debugging, though without the vgdb commands (v.clo, v.info etc). These
> queries elicit no response presumably because valgrind-monitor.py is
> missing from gdb.
The gdb python commands only provide an easier way to use the valgrind
monitor commands.
But if the python code is not loaded, monitor commands can still be used
(but of course prefixed then with the "monitor" gdb command
and not using any of the functionalities that the python layer provides).

Note that monitor command output can be either output to the gdb console
or to the output of the process.
So, you might check both to be sure.

> 
> If you vgdb v.kill the valgrind process, can you and how, get a final
> detail report of all the errors which is generated when the process
> terminates "normally"?
Kill the process really means kill the process, without giving any chance
to let it run more (including to process errors).
If you really need to kill your process but you want to see the errors,
then in memcheck, you should launch a leak search.
And then in all other tools, you can use a monitor command to list
the already found errors.

Philippe

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

On Sat, 2024-07-20 at 11:01 +0200, Philippe Waroquiers via Valgrind-
users wrote:
> On Wed, 2024-07-17 at 20:47 +0200, Julian Seward wrote:
> > Also, there is no gdbserver involved unless you start it with
> > specific
> > flags to invoke GDB support.  But that is not the default.
> 
> Note that the option to activate or not the gdbserver in valgrind is:
>     --vgdb=no|yes|full        activate gdbserver? [yes]
> Default option is yes, which means that the gdbserver is activated
> but has
> no impact on the generated code. With full, the generated code is
> slower but allows
> more precise breakpoints and watchpoints.
I am running with the default 'yes' - so I can query it with shell
vgdb.

> 
> Unless you also use e.g. --vgdb-stop-at= or --vgdb-error=XXXX, 
> -vgdb=yes should have no visible impact and cause no interaction
> between
> different valgrind processes.
> 
I agree there is no interaction in how I am using valgrind (see last
post), but not knowing this before prompted me to ask the question on
this list. I did not use --vgd-stop-at or setup --multi mode of
interacting with gdbserver via gdb. Nevertheless, 'target remote |
vgdb' is equivalent to attaching to the process in gdb, allowing full
debugging, though without the vgdb commands (v.clo, v.info etc). These
queries elicit no response presumably because valgrind-monitor.py is
missing from gdb.

> Note that if --vgdb=no is specified, a set of features (such as
> external control
> from the shell, callgrind_control, ...) will not be available (in
> addition to no 
> no debugging).
Once I attached to the valgrind process from gdb, any further query
from shell vgdb elicits a response I'm busy talking to another client
already, can't talk to you. Detaching in gdb then allows further
queries with shell vgdb. This leads me to another question:

If you vgdb v.kill the valgrind process, can you and how, get a final
detail report of all the errors which is generated when the process
terminates "normally"?

Thanks,
Elaine

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

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

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

On Wed, 2024-07-17 at 20:47 +0200, Julian Seward wrote:
> Also, there is no gdbserver involved unless you start it with specific
> flags to invoke GDB support.  But that is not the default.

Note that the option to activate or not the gdbserver in valgrind is:
    --vgdb=no|yes|full        activate gdbserver? [yes]
Default option is yes, which means that the gdbserver is activated but has
no impact on the generated code. With full, the generated code is slower but allows
more precise breakpoints and watchpoints.

Unless you also use e.g. --vgdb-stop-at= or --vgdb-error=XXXX, 
-vgdb=yes should have no visible impact and cause no interaction between
different valgrind processes.

Note that if --vgdb=no is specified, a set of features (such as external control
from the shell, callgrind_control, ...) will not be available (in addition to no 
no debugging).

Thanks
Philippe

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

On Thu, 2024-07-18 at 07:17 +0200, Julian Seward wrote:
> On 18/07/2024 00:00, Tsiang Elaine Reisler wrote:
> > Yes, there is cross-thread synchronization via shared memory, but
> > not
> > cross-process. I am just running helgrind and drd on exactly the
> > same
> > stand-alone program.
> 
> What CPU are you running this on?
> 
> J
Epyc 7513.

I have done some more experiments. It seems the problem is not in
valgrind. Ordinarily I don't pay much attention to NUMA, just run with
whatever defaults. I can succeed in binding the separate valgrinds to
different nodes, but only by chance, if I start them from various
virtual terminals (same with system consoles). As far as what I want to
do at this point, that is a satisfactory solution.

However, trying to bind valgrind explicitly by numactl --cpunodebind
does not work. It starts and runs valgrind through the first segment.
Everyone sounds happy. But afterwards, that process never gets another
robin round. I have no idea - no search results.

Thanks,
Elaine

PS - apologies for the previous redundant post. I got a rejection
notice by sourceforge because I used a different reply-to address than
my send address. Without checking the list, I made another post.

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Julian S. <jse...@gm...>]

On 18/07/2024 00:00, Tsiang Elaine Reisler wrote:
> Yes, there is cross-thread synchronization via shared memory, but not
> cross-process. I am just running helgrind and drd on exactly the same
> stand-alone program.

What CPU are you running this on?

J

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

On Wed, 2024-07-17 at 20:47 +0200, Julian Seward wrote:
> 
> I don't follow the details exactly, but FWIW .. valgrind running an
> application is "just another normal process".  It has no
> understanding
> of or special-casing relating to NUMA, or particular cores/nodes in a
> multiprocessor machine.
That was my understanding also, that each valgrind instance is stand-
alone - hence two should run on separate nodes the same as on the same
node, but with better access to memory/cpu because they do not have to
contend for them on the same node
> 
> > My conjecture is that the valgrind core is one instance of the
> > gdbserver, which then spawns the tools, and hence one should not
> > force
> 
> Also, there is no gdbserver involved unless you start it with
> specific
> flags to invoke GDB support.  But that is not the default.
> 
> It might be that if you are doing cross-process synchronisation via
> accesses to shared memory, that depend on specific details of the
> machine's
> memory coherence model, that you could wind up with problems. 
> Something
> like that I could believe.
> 
> J
> 
> 
Yes, there is cross-thread synchronization via shared memory, but not
cross-process. I am just running helgrind and drd on exactly the same
stand-alone program.

Thanks,
Elaine
> 

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

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

On Wed, 2024-07-17 at 20:47 +0200, Julian Seward wrote:
> 
> I don't follow the details exactly, but FWIW .. valgrind running an
> application is "just another normal process".  It has no
> understanding
> of or special-casing relating to NUMA, or particular cores/nodes in a
> multiprocessor machine.
That was my understanding also, that each valgrind instance is stand-
alone - hence two should run on separate nodes the same as on the same
node, but with better access to memory/cpu because they do not have to
contend for them on the same node.
> 
> > My conjecture is that the valgrind core is one instance of the
> > gdbserver, which then spawns the tools, and hence one should not
> > force
> 
> Also, there is no gdbserver involved unless you start it with
> specific
> flags to invoke GDB support.  But that is not the default.
> 
> It might be that if you are doing cross-process synchronisation via
> accesses to shared memory, that depend on specific details of the
> machine's
> memory coherence model, that you could wind up with problems. 
> Something
> like that I could believe.
> 
> J
Yes, there is cross-thread synchronization via shared memory, but not
cross-process. I am just running helgrind and drd on exactly the same
stand-alone program.

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

Re: [Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Julian S. <jse...@gm...>]

I don't follow the details exactly, but FWIW .. valgrind running an
application is "just another normal process".  It has no understanding
of or special-casing relating to NUMA, or particular cores/nodes in a
multiprocessor machine.

> My conjecture is that the valgrind core is one instance of the
> gdbserver, which then spawns the tools, and hence one should not force

Also, there is no gdbserver involved unless you start it with specific
flags to invoke GDB support.  But that is not the default.

It might be that if you are doing cross-process synchronisation via
accesses to shared memory, that depend on specific details of the machine's
memory coherence model, that you could wind up with problems.  Something
like that I could believe.

J

[Valgrind-users] Can you run two instances of valgrind on separate nodes in a multi-core NUMA environment?

[Tsiang E. R. <te...@ih...>]

Hi,

It appears that when the default policy is preferred local, the two
instances (one helgrind, one drd) are run on the same node.

I thought I could afford more processor/memory access by forcing the
two instances to run on separate nodes. When I succeeded in doing that,
one process starts up fine, but is apparently not being run, while the
other process proceeds normally. BTW, I am running from /dev/pts in
gnome.

My conjecture is that the valgrind core is one instance of the
gdbserver, which then spawns the tools, and hence one should not force
the tools to run on separate nodes. However, once that is done, it
becomes difficult to correct without restarting the process that is
already running, or maybe even rebooting - too much sunk cost.

So I thought to ask this question while I am waiting.

Thanks,
Elaine