valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] thread not created when program executed with valgrind

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

On 16/01/2024 20:17, JD Silence wrote:
> Hello,
>
> I'm looking for some hints, advice and any other things that could 
> help me figure this out.
>
> I have a big program which I wanted to debug some memory issues. This 
> program internally creates and runs several threads.
>
[snip]
> The program is written in C++ 20. That particular problematic thread 
> is simply created by a line like:
>
> auto thread = new std::thread(&Class::MemberFunction, this, ptr1, ptr2);
>
> So nothing fancy, in my opinion. The debugger reaches that line, and a 
> press to next never enters the breakpoint set in Class::MemberFunction.
>
> In case that could matter, I'm using valgrind 3.19.0 on Debian 12.
>

Not much has changed to the threading/scheduling, unless you are 
changing the thread attributes for priority/scheduling. If so then you 
should try Valgrind 3.22.

Otherwise, try

--fair-sched=yes


A+

Paul

[Valgrind-users] thread not created when program executed with valgrind

[JD S. <sid...@gm...>]

Hello,

I'm looking for some hints, advice and any other things that could help me
figure this out.

I have a big program which I wanted to debug some memory issues. This
program internally creates and runs several threads.

But when launched with valgrind, one of the threads is not created.

Attaching gdb with valgrind, I can break on the line creating the thread, I
can add a breakpoint in that thread function, but it never reaches the
thread function. All other threads are well created and run.

Without valgrind, the thread is well created and runs well. Both with and
without gdb, with and without debugging symbols.

In general, the main program runs well, and never faces issues with
threads. It just exposes some memory issues with a particular dataset which
I want to debug.

The program is written in C++ 20. That particular problematic thread is
simply created by a line like:

auto thread = new std::thread(&Class::MemberFunction, this, ptr1, ptr2);

So nothing fancy, in my opinion. The debugger reaches that line, and a
press to next never enters the breakpoint set in Class::MemberFunction.

In case that could matter, I'm using valgrind 3.19.0 on Debian 12.

Thank you in advance.

[Valgrind-users] A thousand bugs

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

Hi all,

Valgrind is more than 20 years old and we have been collecting
bugs slightly faster than we have been able to close them. Which means
we now have around a thousand bugs open. This is a slightly
intimidating number.

But some of the bugs are more than 10 years old (the oldest bugs are
from 2004). So some of them are likely not really relevant anymore.

If people could do some quick spot checks of some of these bugs that
would be really appreciated.

The bugs can be found here:
https://bugs.kde.org/buglist.cgi?product=valgrind&resolution=---
Or per component here:
https://bugs.kde.org/describecomponents.cgi?product=valgrind

If you filed a bug yourself please look if the issue is still
relevant. Please add a comment saying so if it is, or close it if it
isn't. Same if it has a simple reproducer. If it has a patch attached
please check if it still applies.

Please don't go out of your way to close bugs, even old bugs can still
be relevant. But it would be good to know if they really still are and
we need to take another look at them.

Thanks,

Mark

[Valgrind-users] Valgrind-3.22.0 is available

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

We are pleased to announce a new release of Valgrind, version 3.22.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

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

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 and
AMD64/FreeBSD.  There is also preliminary support for X86/macOS 10.13,
AMD64/macOS 10.13 and nanoMIPS/Linux.

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

* A new configure option --with-gdbscripts-dir lets you install
  the gdb valgrind python monitor scripts in a specific location.
  For example a distro could use it to install the scripts in a
  safe load location --with-gdbscripts-dir=%{_datadir}/gdb/auto-load
  It is also possible to configure --without-gdb-scripts-dir so no
  .debug_gdb_scripts section is added to the vgpreload library and
  no valgrind-monitor python scripts are installed at all.

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

* Support has been added for FreeBSD 14 and FreeBSD 15.
* Add support for the folllowing FreeBSD system calls:
  close_range, kqueuex, membarrier, timerfd_create,
  timerfd_settime and timerfd_gettime (all added in FreeBSD 15).

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

* Memcheck now tests and warns about the values used for
  alignment and size. These apply to various functions: memalign,
  posix_memalign and aligned_alloc in C and various overloads
  of operators new and delete in C++. The kinds of error that can
  be detected are
  - invalid alignment, for instance the alignment is usually required
    to be a power of 2
  - mismatched alignment between aligned allocation and aligned
    deallocation
  - mismatched size when sized delete is used
  - bad size for functions that have implementation defined behaviour
    when the requested size is zero

* Cachegrind:
  - You can now profile part of a program's execution using the new
    `CACHEGRIND_START_INSTRUMENTATION` and `CACHEGRIND_STOP_INSTRUMENTATION`
    client requests, along with the new `--instr-at-start` option. The
    behaviour is the same as Callgrind's equivalent functionality.

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

390871  ELF debug info reader confused with multiple .rodata* sections
417993  vbit-test fail on s390x with Iop_Add32: spurious dependency on uninit
426751  Valgrind reports "still reachable" memory using musl
        (alpine running inside docker)
432801  Valgrind 3.16.1 reports a jump based on uninitialized memory somehow
        related to clang and signals
433857  Add validation to C++17 aligned new/delete alignment size
433859  Add mismatched detection to C++ 17 aligned new/delete
460192  Add epoll_pwait2
461074  DWARF2 CFI reader: unhandled DW_OP_ 0x11 (consts) DW_OP_ 0x92 (bregx)
465782  s390x: Valgrind doesn't compile with Clang on s390x
466105  aligned_alloc problems, part 2
467441  Add mismatched detection to C++ 14 sized delete
469049  link failure on ppc64 (big endian) valgrind 3.20
469146  massif --ignore-fn does not ignore inlined functions
469768  Make it possible to install gdb scripts in a different location
470121  Can't run callgrind_control with valgrind 3.21.0 because of perl errors
470132  s390x: Assertion failure on VGM instruction
470520  Multiple realloc zero errors crash in MC_(eq_Error)
470713  Failure on the Yosys project: valgrind: m_libcfile.c:1802
        (Bool vgPlain_realpath(const HChar *, HChar *)):
        Assertion 'resolved' failed
470830  Don't print actions vgdb me ... continue for vgdb --multi mode
470978  s390x: Valgrind cannot start qemu-kvm when "sysctl vm.allocate_pgste=0"
471311  gdb --multi mode stdout redirecting to stderr
471807  Add support for lazy reading and downloading of DWARF debuginfo
472219  Syscall param ppoll(ufds.events) points to uninitialised byte(s)
472875  none/tests/s390x/dfp-1 failure 
472963  Broken regular expression in configure.ac
473604  Fix bug472219.c compile failure with Clang 16
473677  make check compile failure with Clang 16 based on GCC 13.x
473745  must-be-redirected function - strlen
473870  FreeBSD 14 applications fail early at startup
473944  Handle mold linker split RW PT_LOAD segments correctly
474332  aligned_alloc under Valgrind returns nullptr when alignment is not a multiple of sizeof(void *)
475650  DRD does not work with C11 threads
475652  Missing suppression for __wcsncpy_avx2 (strncpy-avx2.S:308)?
476108  vg_replace_malloc DELETE checks size
n-i-bz  Allow arguments with spaces in .valgrindrc files
n-i-bz  FreeBSD fixed reading of Valgrind tools own debuginfo

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.22.0.RC1: 17 Oct 2023)
(3.22.0.RC2: 26 Oct 2023)

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

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

On 26-10-23 14:48, Mark Wielaard wrote:
> An RC2 tarball for 3.22.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2
> (md5sum = 07bb18b0fd1c7347b350d8d71dc940f6)
> (sha1sum = 61c29e47efdc933ea3f23cb2f0fcebcd6d96dab1)
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2.asc

First, a non-blocking issue
https://bugs.kde.org/show_bug.cgi?id=476320
I'll deal with that after the release

Overall looks OK.

Here are my results:

FreeBSD 13.2 amd64
== 841 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 
0 stdoutB failures, 0 post failures ==

FreeBSD 13.2 x86
== 772 tests, 8 stderr failures, 0 stdout failures, 0 stderrB failures, 
2 stdoutB failures, 0 post failures ==

FreeBSD 12.4 x86
== 768 tests, 7 stderr failures, 0 stdout failures, 1 stderrB failure, 2 
stdoutB failures, 0 post failures ==

FreeBSD 12.4 amd64
== 833 tests, 7 stderr failures, 0 stdout failures, 1 stderrB failure, 1 
stdoutB failure, 0 post failures ==

FreeBSD 14.0 RC3 amd64
== 836 tests, 8 stderr failures, 0 stdout failures, 0 stderrB failures, 
1 stdoutB failure, 0 post failures ==

FreeBSD 14.0 RC3 x86
== 771 tests, 11 stderr failures, 0 stdout failures, 0 stderrB failures, 
2 stdoutB failures, 0 post failures ==

Soalaris 11,3 amd64
== 852 tests, 16 stderr failures, 1 stdout failure, 1 stderrB failure, 0 
stdoutB failures, 9 post failures ==

Illumos (OpenIndiana Hipster 2023.10) amd64
== 858 tests, 79 stderr failures, 16 stdout failures, 18 stderrB 
failures, 20 stdoutB failures, 6 post failures ==

Alpine 3.19 amd64
== 645 tests, 97 stderr failures, 27 stdout failures, 5 stderrB 
failures, 5 stdoutB failures, 5 post failures ==
No change

Alpine 3.19 x86
== 652 tests, 121 stderr failures, 33 stdout failures, 1 stderrB 
failure, 4 stdoutB failures, 5 post failures ==

macOS
== 734 tests, 327 stderr failures, 91 stdout failures, 0 stderrB 
failures, 0 stdoutB failures, 34 post failures ==


A+
Paul

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

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

Hi Eyal,

On Fri, 2023-10-27 at 21:44 -0600, Eyal Soha wrote:
> I have uploaded two possible fixes but I'm unable to test them.  If someone is able to reproduce this bug faithfully, can you try each patch below and let me know if it works?  You can apply the patch with `git am <filename>'.
> 
> Download these:
> 
> https://bugs.kde.org/attachment.cgi?id=162607 (I prefer this one.)
> https://bugs.kde.org/attachment.cgi?id=162608 (If that one doesn't work, maybe this one?)

Very nice analysis. I put some comments in the bug, but in general I
think you found (and fixed) the issue.

> To test, you can run this:
> 
> ./autogen.sh && ./configure && make -j 20 && make -j 20 check && valgrind -q --expensive-definedness-checks=yes memcheck/tests/vbit-test/vbit-test

vbit-test for s390x needs to run from the actual memcheck/tests/vbit-
test (see the source, there is a system call to S390X_FEATURES in it).
But if you run it (with you patch) it works as intended:

$ ../../../vg-in-place --expensive-definedness-checks=yes ./vbit-test 
==2242090== Memcheck, a memory error detector
==2242090== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2242090== Using Valgrind-3.22.0.RC2 and LibVEX; rerun with -h for copyright info
==2242090== Command: ./vbit-test
==2242090== 
==2242090== 
==2242090== HEAP SUMMARY:
==2242090==     in use at exit: 0 bytes in 0 blocks
==2242090==   total heap usage: 256 allocs, 256 frees, 104,448 bytes allocated
==2242090== 
==2242090== All heap blocks were freed -- no leaks are possible
==2242090== 
==2242090== For lists of detected and suppressed errors, rerun with: -s
==2242090== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

and even with the system valgrind:

$ valgrind --expensive-definedness-checks=yes ./vbit-test 
==2242137== Memcheck, a memory error detector
==2242137== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2242137== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==2242137== Command: ./vbit-test
==2242137== 
==2242137== 
==2242137== HEAP SUMMARY:
==2242137==     in use at exit: 0 bytes in 0 blocks
==2242137==   total heap usage: 256 allocs, 256 frees, 104,448 bytes allocated
==2242137== 
==2242137== All heap blocks were freed -- no leaks are possible
==2242137== 
==2242137== For lists of detected and suppressed errors, rerun with: -s
==2242137== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Thanks,

Mark

Re: [Valgrind-users] valgrind usage in arm board

[ramakanth v. <ram...@gm...>]

Hi John,

Thanks a lot for your references ,  below is  valgrind bug filed.

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

Will post further details as I explore.

Thanks
vlrk

On Sat, Sep 30, 2023 at 5:15 AM John Reiser <jr...@bi...> wrote:

> On 9/28/23 20:55, ramakanth varala wrote:
> > I gathered all info at this place https://pastebin.com/1sekb62v <
> https://pastebin.com/1sekb62v>
>
> Looking at the previous messages of the thread in [Valgrind-users] mailing
> list,
> I don't see any information about the context in which you are working.
> Specifically:
>    Which version of valgrind ?  (Run "valgrind --version".)
>    Which hardware?
>    Which operating system and version?
>    Which Linux distribution and software [cross-]development environment?
>    Which compiler and version, and which C run-time library and version?
>
> Some of that info is *required* in order to help you,
> and all of it makes it much easier for maintainers
> to understand what the problem might be.
>
>  From the pastebin posting it apears that you are running Linux
> on a 32-bit ARM system which uses /lib/ld-linux.so.3 as the
> run-time dynamic linker.  But which version of the development
> environment, compiler, and run-time C library?  Yes, it might
> really matter.  Bottom line: give enough information so that
> a maintainer can reproduce the problem that you see.
>
> Getting down to specifics:
> > $ readelf --use-dynamic --symbols ./lib/ld-linux.so.3  >
> /home/labuser/rk/symbols-2.txt
> The use of "./lib/ld-linux.so.3" instead of "/lib/ld-linux.so.3"
> [the difference is a leading dot '.' or not] triggers alarm bells.
> You must be *ABSOLUTELY CERTAIN* that those two files have
> identical contents.  Particularly with "cross-system" environments,
> it is trivially easy for them to differ inadvertently or on purpose.
> Run both 'cmp' and 'sha256sum' to be sure that the contents are the same.
> If the contents are not the same, then you must start over from the
> beginning.
>
> Using a text editor on the contents of the pastebin posting:
> =====
> :g/index$/p
>     857: 0001a300   204 FUNC    LOCAL  DEFAULT   10 index
>
> :g/index$/?Symbol table?p
> Symbol table '.symtab' contains 988 entries:
>
> :g/index$/?$ cat?p
> $ cat /home/labuser/rk/symbols-1.txt
> =====
> Therefore the symbol 'index' does exist in the link-time symbols-1.txt,
> but not in the run-time symbol table symbols-2.txt.  So if the real
> /lib/ld-linux.so.3 has been stripped in order to save space, then
> 'index' will disappear, and valgrind will not be able to find it.
>
> =====
> :g/strchr$/p
>     933: 0001a300   204 FUNC    LOCAL  DEFAULT   10 strchr
>
> :g/strchr$/?Symbol table?p
> Symbol table '.symtab' contains 988 entries:
>
> :g/strchr$/?$ cat?p
> $ cat /home/labuser/rk/symbols-1.txt
> =====
> Therefore 'strchr' is a synonym for 'index', having the same value
> 0x0001a300 and the same properties, but a different name, and a
> different position in the link-time symbol table.
>
> Overall conclusion: you have found a bug in valgrind,
> namely 'index' is optional, and not required as demanded by valgrind.
> (Which version of valgrind?  :-) )
> Please file a bug report, following the directions at
>     https://valgrind.org/support/bug_reports.html
> You will need to supply all the version info of the various pieces,
> and the analysis of which symbols really are present, and _where_.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

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

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

> On 27 Oct 2023, at 00:54, Mark Wielaard <ma...@kl...> wrote:
> 
> Thanks.
> 
> = I ran make regtest on Fedora 38 POWER9 ppc64le and got:
> 
> == 732 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
> memcheck/tests/bug340392                 (stderr)
> drd/tests/std_thread2                    (stderr)
> 
> --- std_thread2.stderr.exp      2023-04-27 15:25:16.109185858 +0000
> +++ std_thread2.stderr.out      2023-10-26 23:12:41.571112420 +0000
> @@ -1,9 +1,14 @@
> 
> Thread 2:
> +Conflicting load by thread 2 at 0x........ size 8
> +   at 0x........: _dl_new_hash (dl-new-hash.h:90)
> +   by 0x........: _dl_lookup_symbol_x (dl-lookup.c:757)
> +Allocation context: Data section of /usr/lib64/ld64.so.2
> +
> Conflicting store by thread 2 at 0x........ size 4
>    at 0x........: main::LAMBDA::operator()() const (std_thread2.cpp:21)
> Allocation context: BSS section of std_thread2
> 
> Done.
> 
> -ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> +ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0)
> 
> I haven't really looked into that more. It is a deterministic
> failure. But I think data races in ld.so should be suppressed?

That’s right. Any non-pthread locking mechanisms in libc libpthread ld.so that generates errors should be suppressed (we assume that these libraries are correct, they would need annotation otherwise).

A+
Paul

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

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

Hi,

On Thu, Oct 26, 2023 at 12:38:04PM -0700, Carl Love via Valgrind-developers wrote:
> Valgrind-3.22.0.RC2 looks good on power. I have run the RC2 on Power
> 10LE, Power 9 LE, Power 8 LE/BE, and Power 7 BE. I see the two failures
> 
> memcheck/tests/bug340392                 (stderr)
> memcheck/tests/linux/rfcomm              (stderr)
> 
> everywhere which is normal.  A couple of the older systems also report
> 
> memcheck/tests/leak_cpp_interior         (stderr)
> memcheck/tests/linux/sys-execveat        (stderr)
> 
> which is also consistent on those platforms.
> 
> It all looks good on PowerPC.

Thanks.

= I ran make regtest on Fedora 38 POWER9 ppc64le and got:

== 732 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/bug340392                 (stderr)
drd/tests/std_thread2                    (stderr)

--- std_thread2.stderr.exp      2023-04-27 15:25:16.109185858 +0000
+++ std_thread2.stderr.out      2023-10-26 23:12:41.571112420 +0000
@@ -1,9 +1,14 @@
 
 Thread 2:
+Conflicting load by thread 2 at 0x........ size 8
+   at 0x........: _dl_new_hash (dl-new-hash.h:90)
+   by 0x........: _dl_lookup_symbol_x (dl-lookup.c:757)
+Allocation context: Data section of /usr/lib64/ld64.so.2
+
 Conflicting store by thread 2 at 0x........ size 4
    at 0x........: main::LAMBDA::operator()() const (std_thread2.cpp:21)
 Allocation context: BSS section of std_thread2
 
 Done.
 
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0)

I haven't really looked into that more. It is a deterministic
failure. But I think data races in ld.so should be suppressed?

= On Fedora 40 (rawhide) x86 (32bit) here are zero failures !

= On Fedora 38 s390x

== 842 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failure, 0 stdoutB failure, 0 post failures ==
memcheck/tests/vbit-test/vbit-test       (stderr)

--- vbit-test.stderr.exp		 2022-02-09 22:47:30.491170867 +0000
+++ vbit-test.stderr.out		 2023-10-26 22:51:38.544254194 +0000
@@ -0,0 +1,3 @@
+Conditional jump or move depends on uninitialised value(s)
+   ...
+

I believe I saw this with 3.21.0 too.

= On RHEL8 x86_64

== 880 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 9 post failures ==
memcheck/tests/overlap                   (stderr)

Which is https://bugs.kde.org/show_bug.cgi?id=402833

Cheers,

Mark

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

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

An RC2 tarball for 3.22.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2
(md5sum = 07bb18b0fd1c7347b350d8d71dc940f6)
(sha1sum = 61c29e47efdc933ea3f23cb2f0fcebcd6d96dab1)
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2.asc

Changes since RC1:

Andreas Arnez (5):
      s390x: Fix memcheck false positives with certain comparisons
      s390x regtest: Fix memcheck tests for cu21 and cu42 with Clang
      Update NEWS to reflect Clang support for s390x
      s390x: Adjust .gitignore after commit 7cf98163adb3f
      s390x regtest: Activate 128 bit SIMD tests for s390x in vbit-test

Carl Love (3):
      Bug 476025 - Powerpc, update expected results for the vbit-test
      Revert "Bug 476025 - Powerpc, update expected results for the
vbit-test"
      Change the vbit test specification for Iop_CmpGT64Ux2

Mark Wielaard (7):
      Add new drd/tests/thrd_create test to .gitignore
      Add arm-linux build artifacts to .gitignore
      vg_replace_malloc DELETE should not check size
      Add 32bit variant of new_aligned_delete_default.stderr.exp
      Add x86 variant of origin5-bz2.stderr.exp-glibc25-amd64-b
      Add new exp files to EXTRA_DIST in memcheck/tests/Makefile.am
      Set version to 3.22.0-RC2

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 Tuesday 31
October.

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

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

Hi,

On Wed, Oct 18, 2023 at 01:04:21AM +0200, Mark Wielaard wrote:
> An RC1 tarball for 3.22.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2
> (md5sum = 786715e301f9b1d3e10faf2a5b360598)
> (sha1sum = ea0e9ca5b5c45168bfcb795e1d19d9d3f5d58223)
> https://sourceware.org/pub/valgrind/valgrind-3.22.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
> 
> RC2 will appear in one week, Tuesday 24 October. And if nothing
> critical emerges after that, a final release will happen a week after
> that on Tuesday 31 October.

I am pushing out RC2 two days to Thursday 26 October so we can get a
fix in for https://bugs.kde.org/show_bug.cgi?id=476025 It is not super
urgent since it looks like a testsuite only issue. But it would be
nice to be able to check the vbit tests correct on all arches.

Cheers,

Mark

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

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

An RC1 tarball for 3.22.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2
(md5sum = 786715e301f9b1d3e10faf2a5b360598)
(sha1sum = ea0e9ca5b5c45168bfcb795e1d19d9d3f5d58223)
https://sourceware.org/pub/valgrind/valgrind-3.22.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

RC2 will appear in one week, Tuesday 24 October. And if nothing
critical emerges after that, a final release will happen a week after
that on Tuesday 31 October.

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

[Karl R. <kro...@zo...>]

On Thursday, October 12, 2023 4:16:17 AM EDT Paul Floyd wrote:
> Yes, a lot of users tend to be confused in thinking that once an object
> has been initialized then it will always be initialized.

I found the problem in my code and it was as you say Paul.  Due to a bug 
elsewhere, some member in the uninitialized part of the structure was being 
used to overwrite a previously set member.

Thanks for your feedback and your continued work on Valgrind! 


-Karl

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

[Karl R. <kro...@zo...>]

On Thursday, October 12, 2023 4:16:17 AM EDT Paul Floyd wrote:
> Yes, a lot of users tend to be confused in thinking that once an object
> has been initialized then it will always be initialized.
> 
> We can't see when is happening between the possibly incomplete
> initialization and the actual error.

You can see the actual errors reported and the memset test line which 
eliminates them here:
    https://github.com/WickedSmoke/xu4/compare/valgrind?expand=1

The memset is before the actual initialization in txf_begin(), so if an 
uninitialized value were assigned later then it should not be changing the 
valgrind report.

The actual struct names are ListDrawState & TxfDrawState and both are plain 
data of 128 bytes & 72 bytes respectively.


-Karl

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

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

On 12/10/2023 08:53, Paul Floyd wrote:
> 
> On 11/10/2023 23:47, Karl Robillard via Valgrind-users wrote:
>> I'm getting the following error on struct members which should absolutely be
>> initialized:
>>    Conditional jump or move depends on uninitialised value(s)
>>
>> To begin investigating I did a memset of zero on the entire struct and the
>> error goes away.  Now this C++ struct inherits another one and the error is
>> reported in C code expecting the base struct.  If I only memset the base
>> struct the error is still reported, which should be impossible.
>>
>> Code summary of the weirdness:
>>
>>      struct ListDrawState : public DrawState { ... };
>>      extern "C" void draw_func(DrawState*);
>>
>>      ListDrawState ds;
>>      memset(&ds, 0, sizeof(DrawState));  // Error in draw_func()
> 
> I don't think that this is legal C++. You can't assume that a C++ class 
> object has the same kind of memory layout as a POD C struct.

That's not any part of the problem code though, so it's not
really relevant to the original problem.

There's no way we can comment on the original problem though
because we can't actually see any of the code, only a few top
level highlights which is nowhere near enough to tell us
anything about what is happening.

Tom

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

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

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

On 12/10/2023 10:06, Tom Hughes wrote:
>
> That's not any part of the problem code though, so it's not
> really relevant to the original problem.
>
> There's no way we can comment on the original problem though
> because we can't actually see any of the code, only a few top
> level highlights which is nowhere near enough to tell us
> anything about what is happening.


Yes, a lot of users tend to be confused in thinking that once an object 
has been initialized then it will always be initialized.

We can't see when is happening between the possibly incomplete 
initialization and the actual error.


Just to explain that first point, in pseudo code

Uninit x; // not initialized

Widget w;

memset w to 0;

// w now all initialized

w.thing = x;

// w.thing now uninitialized


A+

Paul

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

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

On 11/10/2023 23:47, Karl Robillard via Valgrind-users wrote:
> I'm getting the following error on struct members which should absolutely be
> initialized:
>    Conditional jump or move depends on uninitialised value(s)
>
> To begin investigating I did a memset of zero on the entire struct and the
> error goes away.  Now this C++ struct inherits another one and the error is
> reported in C code expecting the base struct.  If I only memset the base
> struct the error is still reported, which should be impossible.
>
> Code summary of the weirdness:
>
>      struct ListDrawState : public DrawState { ... };
>      extern "C" void draw_func(DrawState*);
>
>      ListDrawState ds;
>      memset(&ds, 0, sizeof(DrawState));  // Error in draw_func()

I don't think that this is legal C++. You can't assume that a C++ class 
object has the same kind of memory layout as a POD C struct.

Does this apply in your case?

https://en.cppreference.com/w/cpp/language/ebo

If ListDrawState isn't using EBO then its size will be larger DrawState 
even though it may not add any data members.


In summary, you should either stick to POD structures and then you can 
use memset or else use C++ classes and constructors.


A+

Paul

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

[Karl R. <kro...@zo...>]

I've narrowed down the struct member offset error that Valgrind seems to be 
making.  Uninitialised value errors are being reported for two float members 
with offsets of 36 & 48 bytes into the 72 byte DrawState struct.   Using memset 
to clear just 4 bytes at offset 104 in the ListDrawState causes the error for 
the member at offset 36 to go away.

So before adding the memset the memory at offset 104 is in fact uninitialized.  
The problem is that the actual initialized member used is 68 bytes before that 
at offset 36.


-Karl

[Valgrind-users] Suspect "uninitialised value(s)" error

[Karl R. <kro...@zo...>]

I'm getting the following error on struct members which should absolutely be 
initialized:
  Conditional jump or move depends on uninitialised value(s)

To begin investigating I did a memset of zero on the entire struct and the 
error goes away.  Now this C++ struct inherits another one and the error is 
reported in C code expecting the base struct.  If I only memset the base 
struct the error is still reported, which should be impossible.

Code summary of the weirdness:

    struct ListDrawState : public DrawState { ... };
    extern "C" void draw_func(DrawState*);

    ListDrawState ds;
    memset(&ds, 0, sizeof(DrawState));  // Error in draw_func()
    //memset(&ds, 0, sizeof(ListDrawState));  // No error in draw_func()
    draw_func(&ds);
 
Here's what I'm using to compile and test:
    gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
    valgrind-3.21.0

I've tried to re-create the problem in a stand-alone test, but the error 
doesn't happen there.  If someone wants to look at the actual code I can 
provide a GitHub URL.

-Karl

Re: [Valgrind-users] valgrind usage in arm board

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

On 9/28/23 20:55, ramakanth varala wrote:
> I gathered all info at this place https://pastebin.com/1sekb62v <https://pastebin.com/1sekb62v>

Looking at the previous messages of the thread in [Valgrind-users] mailing list,
I don't see any information about the context in which you are working.
Specifically:
   Which version of valgrind ?  (Run "valgrind --version".)
   Which hardware?
   Which operating system and version?
   Which Linux distribution and software [cross-]development environment?
   Which compiler and version, and which C run-time library and version?

Some of that info is *required* in order to help you,
and all of it makes it much easier for maintainers
to understand what the problem might be.

 From the pastebin posting it apears that you are running Linux
on a 32-bit ARM system which uses /lib/ld-linux.so.3 as the
run-time dynamic linker.  But which version of the development
environment, compiler, and run-time C library?  Yes, it might
really matter.  Bottom line: give enough information so that
a maintainer can reproduce the problem that you see.

Getting down to specifics:
> $ readelf --use-dynamic --symbols ./lib/ld-linux.so.3  > /home/labuser/rk/symbols-2.txt
The use of "./lib/ld-linux.so.3" instead of "/lib/ld-linux.so.3"
[the difference is a leading dot '.' or not] triggers alarm bells.
You must be *ABSOLUTELY CERTAIN* that those two files have
identical contents.  Particularly with "cross-system" environments,
it is trivially easy for them to differ inadvertently or on purpose.
Run both 'cmp' and 'sha256sum' to be sure that the contents are the same.
If the contents are not the same, then you must start over from the beginning.

Using a text editor on the contents of the pastebin posting:
=====
:g/index$/p
    857: 0001a300   204 FUNC    LOCAL  DEFAULT   10 index

:g/index$/?Symbol table?p
Symbol table '.symtab' contains 988 entries:

:g/index$/?$ cat?p
$ cat /home/labuser/rk/symbols-1.txt
=====
Therefore the symbol 'index' does exist in the link-time symbols-1.txt,
but not in the run-time symbol table symbols-2.txt.  So if the real
/lib/ld-linux.so.3 has been stripped in order to save space, then
'index' will disappear, and valgrind will not be able to find it.

=====
:g/strchr$/p
    933: 0001a300   204 FUNC    LOCAL  DEFAULT   10 strchr

:g/strchr$/?Symbol table?p
Symbol table '.symtab' contains 988 entries:

:g/strchr$/?$ cat?p
$ cat /home/labuser/rk/symbols-1.txt
=====
Therefore 'strchr' is a synonym for 'index', having the same value
0x0001a300 and the same properties, but a different name, and a
different position in the link-time symbol table.

Overall conclusion: you have found a bug in valgrind,
namely 'index' is optional, and not required as demanded by valgrind.
(Which version of valgrind?  :-) )
Please file a bug report, following the directions at
    https://valgrind.org/support/bug_reports.html
You will need to supply all the version info of the various pieces,
and the analysis of which symbols really are present, and _where_.

Re: [Valgrind-users] valgrind usage in arm board

[ramakanth v. <ram...@gm...>]

Hi John,

Thanks for the pointers,

I gathered all info at this place https://pastebin.com/1sekb62v

Not very familiar on the valgrind with cross compiled binaries.

Still analysis going on .

Thanks
vlrk

On Wed, Sep 27, 2023 at 10:14 PM John Reiser <jr...@bi...> wrote:

> On 9/26/23 23:15, ramakanth varala wrote:
> > valgrind:  A must-be-redirected function
> > valgrind:  whose name matches the pattern:      index
> > valgrind:  in an object with soname matching:   ld-linux.so.3
> > *valgrind:  was not found whilst processing*
> > *valgrind:  symbols from the object with soname: ld-linux.so.3*
>
> 'index' is identical to 'strchr'.  (Run "man 3 index" to see
> documentation.)
> It might be that the source code for your ld-linux.so has been scoured,
> replacing all calls of 'index(' with calls to 'strchr(' instead.
> If so, then 'index' will not appear in the symbol table,
> and valgrind will have a bug, because: 'index' should be optional.
>
> Please run your app under 'strace':
>      strace -f -o strace.out -e trace=file ./my_app args...
> and look in file strace.out for two kinds of info:
> any line containing "ENOENT" (file not found)
> and any line containing "ld-linux" (part of the actual path used
> for the run-time dynamic linker.)
> Make sure that what you see makes sense.
> Also run "readelf --segments ./my_app" and look for the PT_INTERP.
>
> After discovering the actual path that was used for ld-linux,
> then run "readelf --symbols /path/to/ld-linux  > symbols-1.txt"
> and "readelf --use-dynamic --symbols /path/to/ld-linux  > symbols-2.txt" .
> Then look in both symbols-[12].txt files to see about 'index' AND 'strchr'.
>
>
>
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] valgrind usage in arm board

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

On 9/26/23 23:15, ramakanth varala wrote:
> valgrind:  A must-be-redirected function
> valgrind:  whose name matches the pattern:      index
> valgrind:  in an object with soname matching:   ld-linux.so.3
> *valgrind:  was not found whilst processing*
> *valgrind:  symbols from the object with soname: ld-linux.so.3*

'index' is identical to 'strchr'.  (Run "man 3 index" to see documentation.)
It might be that the source code for your ld-linux.so has been scoured,
replacing all calls of 'index(' with calls to 'strchr(' instead.
If so, then 'index' will not appear in the symbol table,
and valgrind will have a bug, because: 'index' should be optional.

Please run your app under 'strace':
     strace -f -o strace.out -e trace=file ./my_app args...
and look in file strace.out for two kinds of info:
any line containing "ENOENT" (file not found)
and any line containing "ld-linux" (part of the actual path used
for the run-time dynamic linker.)
Make sure that what you see makes sense.
Also run "readelf --segments ./my_app" and look for the PT_INTERP.

After discovering the actual path that was used for ld-linux,
then run "readelf --symbols /path/to/ld-linux  > symbols-1.txt"
and "readelf --use-dynamic --symbols /path/to/ld-linux  > symbols-2.txt" .
Then look in both symbols-[12].txt files to see about 'index' AND 'strchr'.

Re: [Valgrind-users] valgrind usage in arm board

[ramakanth v. <ram...@gm...>]

Hi Paul,

Thanks a lot for reply and inputs.

As said for some it works fine .

In my target board we have busybox binary , this works very fine with
valgrind.

I mean if "ld-linux.so.3 needs to have symbols" ,does this mean busy box
does not use this linker / loader?.

Where as for others it gives error as shown before?.

when I do readelf -S /lib/ld-linux.so.3 , it shows

  [21] .debug_aranges    PROGBITS        00000000 0218f0 0000a0 00      0
0  8
  [22] .debug_info       PROGBITS        00000000 021990 000a81 00      0
0  1
  [23] .debug_abbrev     PROGBITS        00000000 022411 0001b2 00      0
0  1
  [24] .debug_line       PROGBITS        00000000 0225c3 00037f 00      0
0  1
  [25] .debug_frame      PROGBITS        00000000 022944 000608 00      0
0  4
  [26] .debug_str        PROGBITS        00000000 022f4c 0011cf 01  MS  0
0  1
  [27] .debug_loc        PROGBITS        00000000 02411b 0002fb 00      0
0  1

Will this confirm like it has debugging symbols.

You are inputs are very helpful.

Thanks
vlrk




On Wed, Sep 27, 2023 at 1:17 PM Paul Floyd <pj...@wa...> wrote:

>
> On 27/09/2023 08:15, ramakanth varala wrote:
>
>
>
> Not sure enough , what exactly missing , Any inputs in this will be highly
> appreciated.
>
> *valgrind:  symbols from the object with soname: ld-linux.so.3*
>
> Valgrind is looking for symbols in ldrt, the runtime link loader.
>
> Either ld-linux.so.3 needs to have symbols or there needs to be a separate
> debuginfo file.
>
> If the debuginfo is in a non-standard location try
> --extra-debuginfo-path=path and perhaps also
> --allow-mismatched-debuginfo=yes
>
> A+
>
> Paul
>
>

[Valgrind-users] valgrind usage in arm board

[ramakanth v. <ram...@gm...>]

Hi Team,

We are using arm board of i686 arch .

I got valgrind cross compiled using the arm toolchain of i386 ( vendor
given).

We observe for two of the packages could able to run with valgrind .

where as with others I get below error .

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      index
valgrind:  in an object with soname matching:   ld-linux.so.3
*valgrind:  was not found whilst processing*
*valgrind:  symbols from the object with soname: ld-linux.so.3*
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:
*valgrind:    On Debian, Ubuntu:                 libc6-dbg*
*valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo*
*valgrind:*
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.


In above I see like when I do readelf -S ./lib/libc.so.6

 [63] .debug_aranges    PROGBITS        00000000 131558 000240 00      0
0  8
  [64] .debug_info       PROGBITS        00000000 131798 001571 00      0
0  1
  [65] .debug_abbrev     PROGBITS        00000000 132d09 0003dd 00      0
0  1
  [66] .debug_line       PROGBITS        00000000 1330e6 000e17 00      0
0  1
  [67] .debug_frame      PROGBITS        00000000 133f00 002608 00      0
0  4
  [68] .debug_str        PROGBITS        00000000 136508 0012f8 01  MS  0
0  1
  [69] .debug_loc        PROGBITS        00000000 137800 00039b 00      0
0  1

I belive debug symbols are present

Not sure enough , what exactly missing , Any inputs in this will be highly
appreciated.

Thanks
vlrk

Re: [Valgrind-users] how to proceed when faced with malloc error

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

This generally happens when memory errors in the application under test
(here, "btserver") are so bad they wind up trashing Valgrind's storage
too.  If Valgrind has reported memory errors prior to this point, try
fixing them first.

J

> --19817-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - 
> exiting
> --19817-- si_code=128;  Faulting address: 0x0;  sp: 0x100993be30
> 
> valgrind: the 'impossible' happened:
>     Killed by fatal signal
> 
> host stacktrace:
> ==19817==    at 0x580492FF: get_bszB_as_is (m_mallocfree.c:302)
> ==19817==    by 0x580492FF: get_bszB (m_mallocfree.c:314)
> ==19817==    by 0x580492FF: vgPlain_arena_malloc (m_mallocfree.c:1819)
> ==19817==    by 0x58004D74: vgMemCheck_new_block (mc_malloc_wrappers.c:370)
> ==19817==    by 0x58004F99: vgMemCheck___builtin_new (mc_malloc_wrappers.c:415)
> ==19817==    by 0x58093FD5: do_client_request (scheduler.c:1979)
> ==19817==    by 0x58093FD5: vgPlain_scheduler (scheduler.c:1542)
> ==19817==    by 0x580DA8DA: thread_wrapper (syswrap-linux.c:102)
> ==19817==    by 0x580DA8DA: run_a_thread_NORETURN (syswrap-linux.c:155)
> 
> sched status:
>    running_tid=1
> 
> Thread 1: status = VgTs_Runnable (lwpid 19817)
> ==19817==    at 0x4841EF1: operator new(unsigned long) (vg_replace_malloc.c:472)
> ==19817==    by 0x60FFB3: Card::checkNewPort(LFInfo&, String const&, char 
> const*, bool, char const*, bool&, bool&, unsigned int) (Card.cc:7510)
> ==19817==    by 0x611337: Card::discoverDevices(LFInfo&, char const*, bool) 
> (Card.cc:8205)
> ==19817==    by 0x84815E: btserver_main(int, char**) (main.cc:1034)
> ==19817==    by 0x844F64: main (main.cc:157)
> client stack range: [0x1FFEFEA000 0x1FFF000FFF] client SP: 0x1FFEFFDB30
> valgrind stack range: [0x100983C000 0x100993BFFF] top usage: 13936 of 1048576