valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Valgrind taking a lot of time trying to determine if there are memory leaks before it prints "leak summary".

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

On 05-12-24 14:19, Wojciech Bocer wrote:
> Hello,
> 
> I have a problem with Valgrind taking a lot of time trying to
> determine if there are memory leaks before it exits.


Roughly speaking leak detection involves scanning though all accessible 
memory using pointer-size alignment to look for any pointers to unfreed 
memory blocks. This code does handle segfaults.

I don't have any real idea why the combination of x86 and Docker gives 
large numbers of segfaults and a major slowdown.

I suggest that you get the source for Valgrind and set these macros in 
mc_leakcheck.c to 1


// Define to debug the memory-leak-detector.
#define VG_DEBUG_FIND_CHUNK 0
#define VG_DEBUG_LEAKCHECK 0
#define VG_DEBUG_CLIQUE    0

and then build Valgrind.

A+
Paul

Re: [Valgrind-users] Valgrind taking a lot of time trying to determine if there are memory leaks before it prints "leak summary".

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

> Obviously "skipped 195,035,136 bytes due to read errors" does not look good.

So consult the source for valgrind (memcheck) for the string
"skiped.*due to read errors" or similar.  Run memcheck under
a debugger such as gdb, plant a breakpoint on the code that
corresponds to that message, and look a the tracebacks.
(Compile and build memcheck with "-g" option to give debugging info.)

A search of the web for "linux performance monitoring tool"
yields several lists of multiple tools.  Searching for
"linux kernel perf" gives pointers to the 'perf' tool itself.
Of course you may have to add such tools into your VM containers.

[Valgrind-users] Valgrind taking a lot of time trying to determine if there are memory leaks before it prints "leak summary".

[Wojciech B. <woj...@gm...>]

Hello,

I have a problem with Valgrind taking a lot of time trying to
determine if there are memory leaks before it exits.

I'm running Valgrind 3.24.0 with a multi-process 32-bit application in
Linux on x86_64.

This is how I run it:
valgrind --log-file=/tmp/valgrind/memcheck-%p.log --tool=memcheck
--leak-check=summary --time-stamp=yes --track-fds=no
--trace-signals=no --track-origins=no --trace-children=yes
--error-limit=no --verbose my_program

I also use "--trace-children-skip=..." to not trace processes I'm not
interested in, omitted above for readability.

Host: Fedora 41.
VM: Fedora 39. Valgrind has been compiled from source and installed in the VM.
Docker container: Fedora 41, run with docker-compose in privileged
mode. Valgrind has been compiled from source and installed in the
container.

Scenarios:
1. Host -> VM -> I run Valgrind with "leak-check=summary" -> OK.
2. Host -> VM -> Docker Container -> I run Valgrind with "leak-check=no" -> OK.
3. Host -> VM -> Docker Container -> I run Valgrind with
"leak-check=summary" -> NOT OK.

"OK" above means that it took Valgrind "a moment" to analyze the
memory and produce a leak report.
"NOT OK" above means that it took a lot more (10 minutes per process or so).

In order to produce the report I send SIGTERM to my program. All the
child processes call exit(). The main process calls waitpid() and
waits for all children processes. Main process then calls exit().

Scenario 1:
All is fine when I run Valgrind in the VM.

==00:00:00:38.974 223162==
==00:00:00:38.974 223162== Searching for pointers to 472 not-freed blocks
==00:00:00:40.769 223162== Checked 265,221,516 bytes
==00:00:00:40.769 223162==

Scenario 2:
I run Valgrind in a container in a VM.
When running with "leak-check=no" Valgrind also finishes quickly.
Obviously I'm missing the "LEAK SUMMARY" which I need.

Scenario 3:
The problem only appears here, when:
If I run my program and Valgrind in a docker container.
If I enable "leak-check".

==00:00:10:37.904 769== Searching for pointers to 379 not-freed blocks
==00:00:36:34.041 769== Checked 265,208,940 bytes
==00:00:36:34.041 769== Skipped 195,035,136 bytes due to read errors

Notice the timestamps difference between (1) and (3).
The time it takes for Valgrind to search does not seem to depend on
"leak-resolution" or "leak-check-heuristics" settings.

Suspicious:
Obviously "skipped 195,035,136 bytes due to read errors" does not look good.

If I add "--trace-signals=yes", I have to kill valgrind, as it
produces enormous log files for some of the processes.
These log files contain repeated lines, similar to the one below, and
that's the reason for their size (megabytes of text).

==00:00:01:52.043 12423== Searching for pointers to 378 not-freed blocks
--00:00:01:52.237 12423-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002d1d, from kernel
--00:00:01:52.237 12423-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002d1d, from kernel
--00:00:01:52.237 12423-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002d1d, from kernel
...

==00:00:01:43.214 12425== Searching for pointers to 378 not-freed blocks
--00:00:01:43.379 12425-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002d1d, from kernel
--00:00:01:43.379 12425-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002d1d, from kernel
...

==00:00:02:02.470 12443== Searching for pointers to 576 not-freed blocks
--00:00:02:02.677 12443-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002d1d, from kernel
--00:00:02:02.677 12443-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002d1d, from kernel
--00:00:02:02.677 12443-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002d1d, from kernel
...

I was hoping you may offer some advice on what would be the next step
in trying to figure out the root cause of the problem.

Kind regards,
Wojciech

Re: [Valgrind-users] ARM64 executable crashes without Valgrind but runs with Valgrind: Debugging Help Needed

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

On 15-11-24 08:34, Mathew T wrote:
> Hello,
> 
> I’m seeking assistance with a challenging issue involving an
> executable on an ARM64 Ubuntu system. Here’s the problem and what I’ve
> done to investigate it so far:
> 
> Problem Summary: I have an ARM64 executable that crashes with a
> segmentation fault(early to main function, looks like when loading .so
> libraries) when run independently. However, when running it with
> Valgrind, the program completes its execution, although Valgrind does
> report an Invalid free error.

Can you share the source? Even a cut down reproducer?

I've had a quick look at the openssl code. Maybe not the same as your 
version.

void BN_clear_free(BIGNUM *a)
{
     if (a == NULL)
         return;
     if (a->d != NULL && !BN_get_flags(a, BN_FLG_STATIC_DATA))
         bn_free_d(a, 1);
     if (BN_get_flags(a, BN_FLG_MALLOCED)) {
         OPENSSL_cleanse(a, sizeof(*a));
         OPENSSL_free(a);
     }
}

It looks BIGNUM has a member 'd' that actually points to the allocated 
block. I also presume that at the point of failure 'a' is valid and that 
its flags field is also OK.

bn_free_d is probably inlined. I don't see why we don't see the CRYPTO 
function in the callstack. Maybe that's not always used?


> 
> Valgrind Output (partial):
> ===================
> plaintext
> Copy code
> ==2644== Invalid free() / delete / delete[] / realloc()
> ==2644==    at 0x7127AD0: free (in
> /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
> ==2644==    by 0x838C0CB: BN_clear_free (in
> /usr/lib/aarch64-linux-gnu/libcrypto.so.3)
> ==2644==    by 0x7B8CEAB: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644==    by 0x7B9121F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644==    by 0x7B7DF3F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644==    by 0x68C5623: call_init (dl-init.c:70)
> ==2644==    by 0x68C5623: call_init (dl-init.c:26)
> ==2644==    by 0x68C572B: _dl_init (dl-init.c:117)
> ==2644==    by 0x68D7CC7: ??? (in
> /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1)
> ==2644==  Address 0x1 is not stack'd, malloc'd or (recently) free'd

This looks like it's happening before main _dl_init. ld.so loads shared 
libraries and runs any global init code (like C++ constructors).

> Additional Information:
> ====================
> The crash appears to be related to libcrypto and libssh libraries.
> libssh.so.4 and libcrypto.so.3 versions on the system match the
> versions the executable was compiled against.
> I have attempted to gather debug symbols for these libraries to
> analyze further, but only limited information is available from the
> system-provided packages.

Getting debuginfo would help.

> Questions:
> =========
> 1. Could the difference in behavior (running under Valgrind vs.
> standalone) indicate a specific type of issue, such as a memory
> alignment problem?

The memory layout is different when running under valgrind. Mainly the 
stack is in a different place. Allocation alignment is probably the same.

> 2. Are there recommended methods or tools, other than Valgrind and
> GDB, that might help debug memory management issues specifically on
> ARM64?

Sanitizers?

> 3. Has anyone encountered similar issues when libcrypto or libssh
> functions are involved?

No, I don't use Linux arm64 much.

A+
Paul

[Valgrind-users] ARM64 executable crashes without Valgrind but runs with Valgrind: Debugging Help Needed

[Mathew T <mat...@gm...>]

Hello,

I’m seeking assistance with a challenging issue involving an
executable on an ARM64 Ubuntu system. Here’s the problem and what I’ve
done to investigate it so far:

Problem Summary: I have an ARM64 executable that crashes with a
segmentation fault(early to main function, looks like when loading .so
libraries) when run independently. However, when running it with
Valgrind, the program completes its execution, although Valgrind does
report an Invalid free error.

Technical Details:
================
System: Ubuntu ARM64( Jammy)
Executable behavior:

Runs with Valgrind but reports an Invalid free error.
Segmentation fault when running directly, before the main function
starts executing.

Valgrind Output (partial):
===================
plaintext
Copy code
==2644== Invalid free() / delete / delete[] / realloc()
==2644==    at 0x7127AD0: free (in
/usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==2644==    by 0x838C0CB: BN_clear_free (in
/usr/lib/aarch64-linux-gnu/libcrypto.so.3)
==2644==    by 0x7B8CEAB: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
==2644==    by 0x7B9121F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
==2644==    by 0x7B7DF3F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
==2644==    by 0x68C5623: call_init (dl-init.c:70)
==2644==    by 0x68C5623: call_init (dl-init.c:26)
==2644==    by 0x68C572B: _dl_init (dl-init.c:117)
==2644==    by 0x68D7CC7: ??? (in
/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1)
==2644==  Address 0x1 is not stack'd, malloc'd or (recently) free'd

GDB Investigation:
==============
Using gdb on the executable confirms that the crash happens before
reaching main(). Here’s a backtrace from GDB:

(gdb) bt
#0  0x0000000007127ad0 in _vgr10050ZU_VgSoSynsomalloc_free () from
/usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so
#1  0x000000000838c0cc in BN_clear_free () from
/lib/aarch64-linux-gnu/libcrypto.so.3
#2  0x0000000007b8ceac in ?? () from /lib/aarch64-linux-gnu/libssh.so.4
#3  0x0000000007b91220 in ?? () from /lib/aarch64-linux-gnu/libssh.so.4

Additional Information:
====================
The crash appears to be related to libcrypto and libssh libraries.
libssh.so.4 and libcrypto.so.3 versions on the system match the
versions the executable was compiled against.
I have attempted to gather debug symbols for these libraries to
analyze further, but only limited information is available from the
system-provided packages.

Questions:
=========
1. Could the difference in behavior (running under Valgrind vs.
standalone) indicate a specific type of issue, such as a memory
alignment problem?
2. Are there recommended methods or tools, other than Valgrind and
GDB, that might help debug memory management issues specifically on
ARM64?
3. Has anyone encountered similar issues when libcrypto or libssh
functions are involved?

Thank you for any guidance or suggestions you can offer.

Regards,
Matthew

Re: [Valgrind-users] Possibly Lost Error

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

On 12-11-24 22:22, William Chan (BLOOMBERG/ 919 3RD A) wrote:
> Hi,
> 
> I have a program that induces a possibly lost warning via an interior 
> pointer but I deallocate the pointer properly. Is Valgrind supposed to 
> be able to know that an interior pointer is freed? I'm trying to 
> determine whether or not my possibly lost warning is safe to ignore.

Unless something has gone wrong Memcheck redirects and records all calls 
to allocation and deallocation functions. "Interior pointers" are never 
freed, only the original pointers. Passing an interior pointer to 
operator delete or free would result in an "Invalid free() / delete / 
delete[] / realloc()" error.

I think that "possibly lost" is a rather misleading name. There's no 
doubt that the memory is lost. The only doubt is to whether it is really 
a "definite" leak or a "still reachable" (via the interior pointer) one.

See this item on SO for a C++ example.
https://stackoverflow.com/questions/17630892/is-there-a-simple-example-of-false-positive-valgrind-possibly-lost-report

We need more details in order to be sure. Can you share a small example?

A+
Paul

Re: [Valgrind-users] Possibly Lost Error

[David A. <da...@li...>]

On 11/12/24 13:22, William Chan (BLOOMBERG/ 919 3RD A) wrote:
> Hi,
>
> I have a program that induces a possibly lost warning via an interior
> pointer but I deallocate the pointer properly. Is Valgrind supposed to
> be able to know that an interior pointer is freed? I'm trying to
> determine whether or not my possibly lost warning is safe to ignore.

I suggest that a principle of defensive programming is

free(x);
x = 0; /* or x = NULL if you prefer */

Whether this make a difference here ... no idea, sorry.
David Anderson

[Valgrind-users] Possibly Lost Error

[William C. (B. 9. 3. A) <wch...@bl...>]

Hi,

I have a program that induces a possibly lost warning via an interior pointer but I deallocate the pointer properly. Is Valgrind supposed to be able to know that an interior pointer is freed? I'm trying to determine whether or not my possibly lost warning is safe to ignore.

Thanks,
William

[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