valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Virtual Valgrind Fosdem Devroom

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

Hi valgrind hackers,

Valgrind will participate in the Virtual Fosdem on Sunday 6 February
2022 https://fosdem.org/2022/schedule/track/valgrind/

We would like to invite people to propose talks on valgrind by
submitting a talk proposal to 
https://penta.fosdem.org/submission/FOSDEM22
Please select the "Valgrind Devroom" Track.
(If you have any trouble creating a penta login or submission please
contact Julian and me with your proposal.)

Because Fosdem will be virtual this year we will likely ask talks to be
pre-recorded in advance and after playing your presentation we will do
a live Q/A session using Jitsi and Matrix.

Please pick a time that includes the length of your (recorded) talk
plus ~15 minutes Q/A.

We would like to finalize the schedule the first week of January so
that people have enough time to record their talk, so please submit
your proposals before the end of year (31 December 2021).

Some possible topics for talks/discussions are:

- New (or recently added) ports.
- New CPU (instruction) support.
- New (ideas/prototypes) of valgrind tools.
- Valgrind release/bugfixing strategy/policy.
- Advances in gdbserver and the GDB remote serial protocol.
- DWARF, debuginfo, symbols and debuginfod servers.
- Using valgrind with "safe" languages (Rust).
- Adding/Testing Valgrind syscalls support.
- Infrastructure changes (speedups) to the Valgrind JIT framework.
- Your interesting use case with Valgrind.

Sincerely,

Mark & Julian

Re: [Valgrind-users] Using Valgrind with custom memory management

[Oren E. (A. Rahien) <or...@ra...>]

Did you see this?

https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools

On Thu, Nov 18, 2021 at 10:53 AM Abhijit Gokaraju <Abh...@rb...>
wrote:

> Hello Valgrind team,
>
>
>
> We have an application which uses its own memory management (e.g. allocate
> buffer pools of specific sizes).
>
> So, the calls to allocate/free memory do not result in calls to
> malloc()/free().
>
> Only when the buffer pools need more memory, there are calls to
> malloc()/free().
>
>
>
> Could you please suggest if Valgrind has provisions to help detect memory
> leaks, for applications such as ours.
>
> Thanks & Regards,
>
> Abhijit
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
<https://ravendb.net/> *Oren Eini*
*CEO   /   Hibernating Rhinos LTD <https://hibernatingrhinos.com/>*
Mobile:  972-52-548-6969
Sales:  sa...@ra...
Skype:  ayenderahien
Support:  su...@ra...
<https://www.facebook.com/pages/RavenDB/265907650186374>
<https://twitter.com/ravendb>
<https://www.linkedin.com/company/hibernating-rhinos-ltd-/>
<https://ravendb.net/emailsignature/displayeventpage>

Re: [Valgrind-users] Using Valgrind with custom memory management

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

 

> Could you please suggest if Valgrind has provisions to help detect memory leaks, for applications such as ours.


Hi Abhijit

Yes, Valgrind has provisions for this. It will, however, require you to modify your code.

The procedure is documented in the manual here https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools

A+
Paul

[Valgrind-users] Using Valgrind with custom memory management

[Abhijit G. <Abh...@rb...>]

Hello Valgrind team,

We have an application which uses its own memory management (e.g. allocate buffer pools of specific sizes).
So, the calls to allocate/free memory do not result in calls to malloc()/free().
Only when the buffer pools need more memory, there are calls to malloc()/free().

Could you please suggest if Valgrind has provisions to help detect memory leaks, for applications such as ours.
Thanks & Regards,
Abhijit

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

[Valgrind-users] Valgrind-3.18.1 is available

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

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

3.18.1 fixes a number of bugs and adds support for glibc-2.34, and for new
platforms x86/FreeBSD and amd64/FreeBSD.  Debuginfo reading is faster, and
Rust demangling has been improved. For PPC64, ISA 3.1 support has been
completed, and some newer ARM64 and S390 instructions are also supported.  See
the release notes below for details of changes.  Note, 3.18.0 had no formal
release -- it was pulled at the last minute due to a packaging problem.

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.18.0 (15 Oct 2021)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

* The libiberty demangler has been updated, which brings support for
  Rust v0 name demangling

* __libc_freeres isn't called anymore after the program recieves a
  fatal signal. Causing some internal glibc resources to hang around,
  but preventing any crashes after the program has ended.

* The DWARF reader is now very much faster at startup when just
  --read-inline-info=yes (the default in most cases) is given.

* glibc 2.34, which moved various functions from libpthread.so into
  libc.so, is now supported.

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

* arm64:

  - v8.2 scalar and vector FABD, FACGE, FACGT and FADD.
  - v8.2 FP compare & conditional compare instructions.
  - Zero variants of v8.2 FP compare instructions.

* s390:

  - Support the miscellaneous-instruction-extensions facility 3 and
    the vector-enhancements facility 2.  This enables programs
    compiled with "-march=arch13" or "-march=z15" to be executed
    under Valgrind.

* ppc64:

  - ISA 3.1 support is now complete
  - ISA 3.0 support for the darn instruction added.
  - ISA 3.0 support for the vector system call instruction scv added.
  - ISA 3.0 support for the copy, paste and cpabort instructions added.

* Support for X86/FreeBSD and AMD64/FreeBSD has been added.

* ==================== OTHER CHANGES ====================

* Memcheck on amd64: minor fixes to remove some false positive
  undef-value errors

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

208531  [PATCH]: FreeBSD support for valgrind
368960  WARNING: unhandled amd64-linux syscall: 163 (acct)
407589  [Linux] Add support for C11 aligned_alloc() and GNU reallocarray()
423963  Error in child thread when CLONE_PIDFD is used
426148  crash with "impossible happened" when running BPF CO-RE programs
429375  PPC ISA 3.1 support is missing, part 9
431157  PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
431306  Update demangler to support Rust v0 name mangling
432387  s390x: z15 instructions support
433437  FreeBSD support, part 1
433438  FreeBSD support, part 2
433439  FreeBSD support, part 3
433469  FreeBSD support, part 4
433473  FreeBSD support, part 5
433477  FreeBSD support, part 6
433479  FreeBSD support, part 7
433504  FreeBSD support, part 8
433506  FreeBSD support, part 9
433507  FreeBSD support, part 10
433508  FreeBSD support, part 11
433510  FreeBSD support, part 12
433801  PPC ISA 3.1 support is missing, part 10 (ISA 3.1 support complete)
433863  s390x: memcheck/tests/s390x/{cds,cs,csg} failures
434296  s390x: False-positive memcheck diagnostics from vector string
        instructions
434840  PPC64 darn instruction not supported
435665  PPC ISA 3.0 copy, paste, cpabort instructions are not supported
435908  valgrind tries to fetch from deubginfod for files which already
        have debug information
438871  unhandled instruction bytes: 0xF3 0x49 0xF 0x6F 0x9C 0x24 0x60 0x2
439046  valgrind is unusably large when linked with lld
439090  Implement close_range(2)
439326  Valgrind 3.17.0 won't compile with Intel 2021 oneAPI compilers
439590  glibc-2.34 breaks suppressions against obj:*/lib*/libc-2.*so*
440670  unhandled ppc64le-linux syscall: 252 statfs64 and 253 fstatfs64
440906  Fix impossible constraint issue in P10 testcase.
441512  Remove a unneeded / unnecessary prefix check.
441534  Update the expected output for test_isa_3_1_VRT.
442061  very slow execution under Fedora 34 (readdwarf3)
443031  Gcc -many change requires explicit .machine directives
443033  Add support for the ISA 3.0 mcrxrx instruction
443034  Sraw, srawi, srad, sradi, mfs
443178  Powerpc, test jm-mfspr expected output needs to be updated.
443179  Need new test for the lxvx and stxvx instructions on ISA 2.07 and
        ISA 3.0 systems.
443180  The subnormal test and the ISA 3.0 test generate compiler warnings
443314  In the latest GIT version, Valgrind with "--trace-flags" crashes
        at "al" register
443605  Don't call final_tidyup (__libc_freeres) on FatalSignal

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

(3.18.0.RC1: 12 Oct 2021)
(3.18.0:     15 Oct 2021)

MD5SUM:  de56a5532b0c81781db677ca712c585a         valgrind-3.18.1.tar.bz2
SHA1SUM: 0a694a8d0c2152978bf64b67ad0b3dd972bbeb54 valgrind-3.18.1.tar.bz2

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

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

At 2021-11-10 01:18Z, Kyryl Melekhin wrote:
> Ok, stop. I forgot, the executables likely won't work because my MuslC was
> -march native optimized. And obviously static linking will include that code.

Whn I look at this file:
     $ ls -l piketcc  # compiled by tcc
     -rwxr-xr-x. 1 user group 80208 Nov 10 20:38Z  piketcc
     $ sha256sum piketcc
     6579786352c53de2fc8dc8322b866256870b911fc1b700202889b6fee9a45ff4  piketcc

disassembled by gdb, and next examined in a text editor, then I see
curious manipulation of the stack pointer %rsp:

Dump of assembler code for function re_pikevm:  [VLA = Variable-Length Array]
:g/%rsp,/p   ## direct reads of the stack pointer
    0x000000000040235f <+1>:     mov    %rsp,%rbp  # Frame pointer at entry
    0x00000000004023e1 <+131>:   mov    %rsp,-0x88(%rbp)  # remember the address of a VLA
    0x00000000004023f2 <+148>:   mov    %rsp,-0x80(%rbp)
    0x0000000000402416 <+184>:   mov    %rsp,-0x98(%rbp)
    0x000000000040243d <+223>:   mov    %rsp,-0xa8(%rbp)
    0x0000000000402489 <+299>:   mov    %rsp,-0x7a1f8(%rbp)
    0x00000000004024b3 <+341>:   mov    %rsp,-0x7a208(%rbp)

:g/,%rsp/p   ## writes to the stack pointer
    0x0000000000402362 <+4>:     sub    $0x7a240,%rsp  # allocate fixed portion of stack frame
    0x00000000004023eb <+141>:   sub    %rax,%rsp  # allocate a VLA: %rsp -= %rax
    0x00000000004023ee <+144>:   and    $0xfffffffffffffff0,%rsp  # 16-byte align a VLA
    0x000000000040240f <+177>:   sub    %rax,%rsp
    0x0000000000402412 <+180>:   and    $0xfffffffffffffff0,%rsp
    0x0000000000402436 <+216>:   sub    %rax,%rsp
    0x0000000000402439 <+219>:   and    $0xfffffffffffffff0,%rsp
    0x0000000000402482 <+292>:   sub    %rax,%rsp
    0x0000000000402485 <+295>:   and    $0xfffffffffffffff0,%rsp
    0x00000000004024ac <+334>:   sub    %rax,%rsp
    0x00000000004024af <+337>:   and    $0xfffffffffffffff0,%rsp
    0x00000000004024fa <+412>:   mov    -0x88(%rbp),%rsp
    0x00000000004026c4 <+870>:   mov    -0x7a208(%rbp),%rsp
    0x00000000004026ec <+910>:   mov    -0x7a208(%rbp),%rsp
    0x00000000004026f3 <+917>:   mov    -0x7a208(%rbp),%rsp
    0x000000000040272c <+974>:   mov    -0x7a208(%rbp),%rsp
    0x000000000040278d <+1071>:  mov    -0x7a208(%rbp),%rsp
    0x00000000004027de <+1152>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402e3e <+2784>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402e8c <+2862>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402f63 <+3077>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402fbc <+3166>:  mov    -0x7a208(%rbp),%rsp
    0x000000000040309c <+3390>:  mov    -0x7a208(%rbp),%rsp
    0x00000000004030fd <+3487>:  mov    -0x7a208(%rbp),%rsp
    0x000000000040314e <+3568>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000403683 <+4901>:  mov    -0x88(%rbp),%rsp
    0x0000000000403813 <+5301>:  mov    -0x88(%rbp),%rsp
    0x0000000000403824 <+5318>:  mov    -0x88(%rbp),%rsp


When run with command-line arguments "./piketcc abc abc", then examination
of all the "mov -0x7a208(%rbp),%rsp" instructions shows that the value
in register %rsp does not change.  I wonder if valgrind does something
strange here, such as marking some portion of the fixed frame as uninit
even though nothing changes.

The corresponding pikegcc never re-loads %rsp after allocating the VLAs:
     $ ls -l pikegcc
     -rwxr-xr-x. 1 user group 72960 Nov 10 20:37Z pikegcc
     $ sha256sum pikegcc
     952ce60eb5f66445f08d8ffc14b348febdefc99f4985cd4e725ae3d1682246c8  pikegcc

:g/%rsp,/p  # direct reads of stack pointer %rsp
    0x40328d <re_pikevm+1>:      mov    %rsp,%rbp
    0x000000000040328d <+1>:     mov    %rsp,%rbp
    0x00000000004032ca <+62>:    mov    %rsp,%rax
    0x0000000000403395 <+265>:   mov    %rsp,%rax
    0x0000000000403406 <+378>:   mov    %rsp,%rax
    0x0000000000403489 <+509>:   mov    %rsp,%rax
    0x0000000000403523 <+663>:   mov    %rsp,%rax
    0x00000000004035a7 <+795>:   mov    %rsp,%rax
:g/,%rsp/p  # writes to register %rsp
    0x403299 <re_pikevm+13>:     sub    $0x7a298,%rsp
    0x0000000000403299 <+13>:    sub    $0x7a298,%rsp
    0x0000000000403392 <+262>:   sub    %rax,%rsp  # allocate VLA; %rax is pre-aligned to (0 mod 16)
    0x0000000000403403 <+375>:   sub    %rax,%rsp
    0x0000000000403486 <+506>:   sub    %rax,%rsp
    0x0000000000403520 <+660>:   sub    %rax,%rsp
    0x00000000004035a4 <+792>:   sub    %rax,%rsp
    0x0000000000404956 <+5834>:  mov    %rbx,%rsp
    0x000000000040496d <+5857>:  lea    -0x28(%rbp),%rsp  # begin subroutine epilog

Investigation continues...

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[Kyryl M. <k.m...@gm...>]

I think I might have an idea about the cause of this error now.
If you read the CodingStyle file located at the root of tcc directory
it mentions:
"
- Test with Valgrind to detect some uses of uninitialised values:
make clean
./configure
make
# On Intel, because Valgrind does floating-point arithmetic differently:
( cd tests && gcc -I.. tcctest.c && valgrind -q ./a.out > test.ref )
make test TCC="valgrind -q --leak-check=full `pwd`/tcc -B`pwd` -I`pwd`"
(Because of how VLAs are implemented, invalid reads are expected
with 79_vla_continue.)"

This file has not been updated in 6 years, but I know for a fact
that there have been some patches and fixes applied to VLAs
in that time. My code does make extensive use of VLA and that
might be the offending root cause here. But now I am 100%
sure what the problem is. If I replace the VLA with malloc
the error vanishes.

So the question is up for debate: tcc generates VLA code that
seems wrong in the eyes of valgrind. Though this code is not
necessarily invalid. If the code is not invalid then it must be
valgrind fault and not tcc.

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[Kyryl M. <k.m...@gm...>]

Ok, stop. I forgot, the executables likely won't work because my MuslC was
-march native optimized. And obviously static linking will include that code.

I've updated the executables and verified that they do indeed run on lower spec
hardware.

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[Kyryl M. <k.m...@gm...>]

(This is a CC to mailing list)
Hello John,

Thanks for the suggestion.
Here are the executables (both statically linked with musl, they will
work under any linux kernel 2.0+):
This is my personal website, feel free to download.
https://kyryl.tk/pikegcc
https://kyryl.tk/piketcc

both compiled with
tcc pike.c -g -static -o piketcc
gcc pike.c -g -static -o pikegcc

gcc 11.20 release
tcc (git+git://repo.or.cz/tinycc.git) last commit

My software build environment is nothing too out of the ordinary, it's
all bleeding edge
from the git repos. I don't run some hopelessly outdated system or
anything like that.
Personally I would find it simple to recreate from source, but
anyways, here is a screenshot
to better aid in understanding what I am looking at.

https://kyryl.tk/2021-11-10-002850_2559x1413_scrot.png

What's interesting is even if there is an error and tcc produces bad code,
how to does it manage to pass 150+ various test cases non stop
for a few hours without faulting once, if as you can see on the screenshot
the error gets detected in the simplest of cases imaginable.

It seems very likely that valgrind is at fault here. Both gcc and clang
compiled versions work with no errors from valgrind on any optimization level.

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

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

On 11/9/21 14:16, Kyryl Melekhin wrote:
> Hello,
> 
> I am almost certain to have found a bug in valgrind.
> The false positive error appears only when compiled with
> tcc compiler. The platform is x86_64 linux, musl.
> 
> I can reproduce it in my regex engine and I have created
> the following branch for you to check it out:
> https://github.com/kyx0r/pikevm/tree/valgrind_bug
 >    [[snip]]

If the problem is compiler-dependent, and if pikevm is as small as advertised,
then the best thing for *you* to do is to produce two complete runnable
executable programs, which are "the same" except that one has the suspected
bug (thus is compiled with tcc for x86_64, and linked with musl to run
under Linux), and the other does not (the same source compiled with some other
compiler [specify and include its version], and linked with musl to run under
Linux.)

Provide a URL to each executable file.  Almost nobody will go to the trouble
of re-creating your unspecified software build environment (which version of
tcc and where to get it, which version of musl and where to get it, etc.)
just to investigate the alleged bug.

Your recipe [snipped above] does not matter.  If *you* cannot be bothered to
execute the recipe and provide URL to the results, then it is extremely
likely that no one else will bother, either.  Various hosting services
provide no-cost or low-cost download service, and even GitHub allows attachments
and other ways to provide access to non-humongous executable files.  Use one.

[Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[Kyryl M. <k.m...@gm...>]

Hello,

I am almost certain to have found a bug in valgrind.
The false positive error appears only when compiled with
tcc compiler. The platform is x86_64 linux, musl.

I can reproduce it in my regex engine and I have created
the following branch for you to check it out:
https://github.com/kyx0r/pikevm/tree/valgrind_bug

Diff last commit on that branch, the valgrind_bug.sh runs
compiles pike.c with tcc and runs it to show the false report.
I have added a comment where the so called "uninitialized value"
comes from.

I am using the latest git commit of tcc and valgrind. This error
does not happen on any other compiler, any optimization level.
Code generated by tcc does not seem to produce any erroneous
results. Not a single defect, segfault or anything has ever been found.

I am also confident that code like this is permitted by the C standard
as its simple pointer arithmetic. *(p - 1)

The test cases in tesh.sh, specifically those around cases 130-150
certainly will fail if there actually is an uninitialized variable. If
somehow the result of this branch:
if (*nlist[nlistidx-1].pc == MATCH)
          break;
gets tampered with the test case fails %100.

What i've done to test, I have put the test suite into an infinite loop and
it keeps running without ever failing, so that means there is never
uninitialized
variable there, and it's also obvious if you read the code, why it will never be
that. It has been running for a few hours now. Usually chances of seeing the
effects take a few runs, here is not the case.

I know this is not the dev mailing list, please forward it to them.
This is a very interesting case to investigate, as this questions the broader
validity of valgrind's uninitialized value tracking.

Re: [Valgrind-users] Cubic root of zero gives wrong result with clang 64-bit

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

On 21/10/2021 20:45, Florian Weimer wrote:
> * Paul Floyd:
>
>> Unless someone else has an Idea this is going to need some debugging
>> inside Valgrind.
> It's probably the glibc implementation that is incorrectly executed by
> valgrind.  “g++ -fno-builtin” reproduces the issue with the original
> sources.


Yes, this is what is happening. Stepping through libc cbrtl with 
debuginfo, outside of Valgrind the return is where the arrow is, 
presumably fpclassify saying that it is FP_ZERO. xe is an int, can't 
imagine comparing it to zero is going to be a problem.

   54            if (xe == 0 && fpclassify (x) <= FP_ZERO) │
 >55              return x + x;


The enum values returned by fpclassify are FP_NAN 0, FP_INFINITE 1, 
FP_ZERO 2.

Inside Valgrind this test is false, and the (wrong) value that is 
calculated corresponds to the expressions and constants in the code.


#  define fpclassify(x) __builtin_fpclassify (FP_NAN, 
FP_INFINITE,            \
      FP_NORMAL, FP_SUBNORMAL, FP_ZERO, x)


 From what I see this builtin performs

   /* fpclassify(x) ->
        isnan(x) ? FP_NAN :
          (fabs(x) == Inf ? FP_INFINITE :
            (fabs(x) >= DBL_MIN ? FP_NORMAL :
              (x == 0 ? FP_ZERO : FP_SUBNORMAL))).  */


For the first test, it looks like there is a 'fucomi'.That will set the 
parity flag if the input is NaN, but I only see ZF set.

The next test is another 'fucomi' comparing to the largest long double 
followed by a 'ja', testing for Inf. The result is just CF set - less than.

The third test is a 'fcompi' with ldbl_min. This sets ZF, and is 
followed by a 'jae'. That's wrong. That would mean 0.0 == ldbl_min.

If internally we are working with double precision that it's to be 
expected that ldbl_min underflows to 0.0 and the comparison is true.


It's a shame the libc test is done in this order. I don't see any easy 
fix for this.


A+

Paul

Re: [Valgrind-users] Cubic root of zero gives wrong result with clang 64-bit

[Florian W. <fw...@de...>]

* Paul Floyd:

> Unless someone else has an Idea this is going to need some debugging 
> inside Valgrind.

It's probably the glibc implementation that is incorrectly executed by
valgrind.  “g++ -fno-builtin” reproduces the issue with the original
sources.

Re: [Valgrind-users] Cubic root of zero gives wrong result with clang 64-bit

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

On 20/10/2021 20:13, Paul Floyd wrote:

> On 10/20/21 16:16, Paul FLOYD wrote:
>
>>> Message du 20/10/21 17:14
>>>
>>> De : "Vladislav Yaglamunov"
>>>
>>> A : val...@li...
>>>
>>> Copie à :
>>>
>>> Objet : [Valgrind-users] Cubic root of zero gives wrong result with 
>>> clang 64-bit
>>>
>>> I am using Valgrind 3.17.0 and noticed a strange behavior while 
>>> running a code compiled with clang:
>>>
>> #include
>>
>>> int main() {
>>>
>>>      long double x = std::cbrtl(0.0L);
>>>
>>>      printf("%Lf", x);
>>>
>>>      return 0;
>>>
>>> }
>>>
>> I just did a test with g++. I had to modify the code a bit to prevent 
>> the compiler replacing the cbrtl() call with just a zero:
>>
>> #include <cmath>
>>
>> #include <
>>
>> int main() {
>>
>> volatile long double arg{0.0L};
>>
>> long double x = std::cbrtl(arg);
>>
>> printf("%Lf", x);
>>
>> return 0;
>>
>> }
>>
>> This seems to work OK, both default and -m32.
>>
>> The asm for that is
>>
>> 00000000004011a5 :
>>
>> 4011a5: 55              push %rbp
>>
>> 4011a6: 48 89 e5        mov %rsp,%rbp
>>
>> 4011a9: 48 83 ec 20     sub $0x20,%rsp
>>
>> 4011ad: d9 ee           fldz
>>
>> 4011af: db 7d e0        fstpt -0x20(%rbp)
>>
>> 4011b2: db 6d e0        fldt -0x20(%rbp)
>>
>> 4011b5: 48 8d 64 24 f0  lea -0x10(%rsp),%rsp
>>
>> 4011ba: db 3c 24        fstpt (%rsp)
>>
>> 4011bd: e8 8e fe ff ff  callq 401050
>>
>> 4011c2: 48 83 c4 10     add $0x10,%rsp
>>
>> 4011c6: db 7d f0        fstpt -0x10(%rbp)
>>
>> 4011c9: ff 75 f8        pushq -0x8(%rbp)
>>
>> 4011cc: ff 75 f0        pushq -0x10(%rbp)
>>
>> 4011cf: bf 04 20 40 00  mov $0x402004,%edi
>>
>> 4011d4: b8 00 00 00 00  mov $0x0,%eax
>>
>> 4011d9: e8 62 fe ff ff  callq 401040
>>
>> 4011de: 48 83 c4 10     add $0x10,%rsp
>>
>> 4011e2: b8 00 00 00 00  mov $0x0,%eax
>>
>> 4011e7: c9              leaveq
>>
>> 4011e8: c3              retq
>>
> Well, it works with clang++:
>
> FreeBSD clang version 11.0.1 (gi...@gi...:llvm/llvm-project.git 
> llvmorg-11.0.
>
> 1-0-g43ff75f2c3fe)
>
> Target: x86_64-unknown-freebsd13.0
>
> I also tried clang++ 8, 9 and 12.
>
> The asm for clang++12 for my modified code is
>
> 0000000000201920 <main>:
>
>  201920:       55                      push   %rbp
>
>  201921:       48 89 e5                mov    %rsp,%rbp
>
>  201924:       48 83 ec 40             sub    $0x40,%rsp
>
>  201928:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%rbp)
>
>  20192f:       d9 ee                   fldz
>
>  201931:       db 7d e0                fstpt  -0x20(%rbp)
>

> 201934:       db 6d e0                fldt   -0x20(%rbp)
> 201937:       48 89 e0                mov    %rsp,%rax
> 20193a:       db 38                   fstpt  (%rax)
> 20193c:       e8 bf 00 00 00          call   201a00 <cbrtl@plt>
> 201941:       db 7d d0                fstpt  -0x30(%rbp)
> 201944:       db 6d d0                fldt   -0x30(%rbp)
> 201947:       48 89 e0                mov    %rsp,%rax
> 20194a:       db 38                   fstpt  (%rax)
> 20194c:       bf c9 05 20 00          mov    $0x2005c9,%edi
> 201951:       31 c0                   xor    %eax,%eax
> 201953:       e8 b8 00 00 00          call   201a10 <printf@plt>
> 201958:       31 c0                   xor    %eax,%eax
> 20195a:       48 83 c4 40             add    $0x40,%rsp
> 20195e:       5d                      pop    %rbp
> 20195f:       c3                      ret
>
> Can you post the asm that you are getting ? I'll see if I can try 
> clang on Fedora 34.
>

Third time lucky. Reproduced on Fedora 34 with clang++

clang version 12.0.1 (Fedora 12.0.1-1.fc34)

0000000000401140 <main>:
  401140:       55                      push   %rbp
  401141:       48 89 e5                mov    %rsp,%rbp
  401144:       48 83 ec 40             sub    $0x40,%rsp
  401148:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%rbp)
  40114f:       d9 ee                   fldz
  401151:       db 7d e0                fstpt  -0x20(%rbp)
  401154:       db 6d e0                fldt   -0x20(%rbp)
  401157:       48 89 e0                mov    %rsp,%rax
  40115a:       db 38                   fstpt  (%rax)
  40115c:       e8 df fe ff ff          callq  401040 <cbrtl@plt>
  401161:       db 7d d0                fstpt  -0x30(%rbp)
  401164:       db 6d d0                fldt   -0x30(%rbp)
  401167:       48 89 e0                mov    %rsp,%rax
  40116a:       db 38                   fstpt  (%rax)
  40116c:       bf 10 20 40 00          mov    $0x402010,%edi
  401171:       31 c0                   xor    %eax,%eax
  401173:       e8 b8 fe ff ff          callq  401030 <printf@plt>
  401178:       31 c0                   xor    %eax,%eax
  40117a:       48 83 c4 40             add    $0x40,%rsp
  40117e:       5d                      pop    %rbp

  40117f:       c3                      retq


That looks very much like what I saw on FreeBSD.


Unless someone else has an Idea this is going to need some debugging 
inside Valgrind.


A+

Paul

Re: [Valgrind-users] Cubic root of zero gives wrong result with clang 64-bit

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

On 10/20/21 16:16, Paul FLOYD wrote:
>> Message du 20/10/21 17:14
>> De : "Vladislav Yaglamunov"
>> A : val...@li...
>> Copie à :
>> Objet : [Valgrind-users] Cubic root of zero gives wrong result with clang 64-bit
>>
>> I am using Valgrind 3.17.0 and noticed a strange behavior while running a code compiled with clang:
> #include
>> int main() {
>>      long double x = std::cbrtl(0.0L);
>>      printf("%Lf", x);
>>
>>      return 0;
>> }
> I just did a test with g++. I had to modify the code a bit to prevent the compiler replacing the cbrtl() call with just a zero:
>
> #include <cmath>
> #include <
>
> int main() {
> volatile long double arg{0.0L};
> long double x = std::cbrtl(arg);
> printf("%Lf", x);
>
> return 0;
> }
>
> This seems to work OK, both default and -m32.
>
>
> The asm for that is
>
> 00000000004011a5 :
> 4011a5: 55              push %rbp
> 4011a6: 48 89 e5        mov %rsp,%rbp
> 4011a9: 48 83 ec 20     sub $0x20,%rsp
> 4011ad: d9 ee           fldz
> 4011af: db 7d e0        fstpt -0x20(%rbp)
> 4011b2: db 6d e0        fldt -0x20(%rbp)
> 4011b5: 48 8d 64 24 f0  lea -0x10(%rsp),%rsp
> 4011ba: db 3c 24        fstpt (%rsp)
> 4011bd: e8 8e fe ff ff  callq 401050
> 4011c2: 48 83 c4 10     add $0x10,%rsp
> 4011c6: db 7d f0        fstpt -0x10(%rbp)
> 4011c9: ff 75 f8        pushq -0x8(%rbp)
> 4011cc: ff 75 f0        pushq -0x10(%rbp)
> 4011cf: bf 04 20 40 00  mov $0x402004,%edi
> 4011d4: b8 00 00 00 00  mov $0x0,%eax
> 4011d9: e8 62 fe ff ff  callq 401040
> 4011de: 48 83 c4 10     add $0x10,%rsp
> 4011e2: b8 00 00 00 00  mov $0x0,%eax
> 4011e7: c9              leaveq
> 4011e8: c3              retq


Well, it works with clang++:

FreeBSD clang version 11.0.1 (gi...@gi...:llvm/llvm-project.git 
llvmorg-11.0.
1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd13.0


I also tried clang++ 8, 9 and 12.


The asm for clang++12 for my modified code is


0000000000201920 <main>:
  201920:       55                      push   %rbp
  201921:       48 89 e5                mov    %rsp,%rbp
  201924:       48 83 ec 40             sub    $0x40,%rsp
  201928:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%rbp)
  20192f:       d9 ee                   fldz
  201931:       db 7d e0                fstpt  -0x20(%rbp)
  201934:       db 6d e0                fldt   -0x20(%rbp)
  201937:       48 89 e0                mov    %rsp,%rax
  20193a:       db 38                   fstpt  (%rax)
  20193c:       e8 bf 00 00 00          call   201a00 <cbrtl@plt>
  201941:       db 7d d0                fstpt  -0x30(%rbp)
  201944:       db 6d d0                fldt   -0x30(%rbp)
  201947:       48 89 e0                mov    %rsp,%rax
  20194a:       db 38                   fstpt  (%rax)
  20194c:       bf c9 05 20 00          mov    $0x2005c9,%edi
  201951:       31 c0                   xor    %eax,%eax
  201953:       e8 b8 00 00 00          call   201a10 <printf@plt>
  201958:       31 c0                   xor    %eax,%eax
  20195a:       48 83 c4 40             add    $0x40,%rsp
  20195e:       5d                      pop    %rbp
  20195f:       c3                      ret

Can you post the asm that you are getting ? I'll see if I can try clang 
on Fedora 34.


A+

Paul

Re: [Valgrind-users] Cubic root of zero gives wrong result with clang 64-bit

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

> Message du 20/10/21 17:14
> De : "Vladislav Yaglamunov" 
> A : val...@li...
> Copie à : 
> Objet : [Valgrind-users] Cubic root of zero gives wrong result with clang 64-bit
> 
>Hi,

>I am using Valgrind 3.17.0 and noticed a strange behavior while running a code compiled with clang:

>
> #include 
> 
> int main() {
>     long double x = std::cbrtl(0.0L);
>     printf("%Lf", x);
> 
>     return 0;
> }

I just did a test with g++. I had to modify the code a bit to prevent the compiler replacing the cbrtl() call with just a zero:

#include 
#include 

int main() {
volatile long double arg{0.0L};
long double x = std::cbrtl(arg);
printf("%Lf", x);

return 0;
}

This seems to work OK, both default and -m32.


The asm for that is

00000000004011a5 :
4011a5: 55 push %rbp
4011a6: 48 89 e5 mov %rsp,%rbp
4011a9: 48 83 ec 20 sub $0x20,%rsp
4011ad: d9 ee fldz
4011af: db 7d e0 fstpt -0x20(%rbp)
4011b2: db 6d e0 fldt -0x20(%rbp)
4011b5: 48 8d 64 24 f0 lea -0x10(%rsp),%rsp
4011ba: db 3c 24 fstpt (%rsp)
4011bd: e8 8e fe ff ff callq 401050 
4011c2: 48 83 c4 10 add $0x10,%rsp
4011c6: db 7d f0 fstpt -0x10(%rbp)
4011c9: ff 75 f8 pushq -0x8(%rbp)
4011cc: ff 75 f0 pushq -0x10(%rbp)
4011cf: bf 04 20 40 00 mov $0x402004,%edi
4011d4: b8 00 00 00 00 mov $0x0,%eax
4011d9: e8 62 fe ff ff callq 401040 

4011de: 48 83 c4 10 add $0x10,%rsp
4011e2: b8 00 00 00 00 mov $0x0,%eax
4011e7: c9 leaveq
4011e8: c3 retq


I'll have a go with clang++ at home tonight.

A+
Paul

[Valgrind-users] Cubic root of zero gives wrong result with clang 64-bit

[Vladislav Y. <vl...@so...>]

Hi,

I am using Valgrind 3.17.0 and noticed a strange behavior while running a
code compiled with clang:

#include <cmath>
#include <cstdio>

int main() {
    long double x = std::cbrtl(0.0L);
    printf("%Lf", x);

    return 0;
}

This example gives complete wrong output:

clang++ cbrtl.cpp -o cbrtl && valgrind ./cbrtl
==338929== Memcheck, a memory error detector
==338929== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==338929== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright
info
==338929== Command: ./cbrtl
==338929==
-0.178840
==338929==
==338929== HEAP SUMMARY:
==338929==     in use at exit: 0 bytes in 0 blocks
==338929==   total heap usage: 2 allocs, 2 frees, 73,728 bytes allocated
==338929==
==338929== All heap blocks were freed -- no leaks are possible
==338929==
==338929== For lists of detected and suppressed errors, rerun with: -s
==338929== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

However, using -m32 option for clang or gcc compiler (both 32 and 64-bit)
prints 0.0 as expected. I know that valgrind does not support 80-bit long
double and converts it to 64-bit.
I think it might cause this issue as the original code is compiled for
80-bit long doubles. It also might be an issue with clang.

Regards,
Vlad Yaglamunov

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

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

On 10/12/21 10:13 PM, Mark Wielaard wrote:
> An RC1 tarball for 3.18.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.18.0.RC1.tar.bz2
> (md5sum = 6babaf9e145055a2c9b50cbd2ddfefc0)
> (sha1sum = ccc73895097cba83cf7664b02edc66866e98a31b)
>
> 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 Friday
> 15 October.


Hi Mark

I've tested on FreeBSD 12.2 and 13.0. Both as expected.

Additionally I've tried Solaris 11.3 (OK and no change) and macOS 10.7.5 
(not very good but no change either).

It's a green light for me.


Cheers

Paul

[Valgrind-users] valgrind-3.18.0.RC1 is available for testing

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

An RC1 tarball for 3.18.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.18.0.RC1.tar.bz2
(md5sum = 6babaf9e145055a2c9b50cbd2ddfefc0)
(sha1sum = ccc73895097cba83cf7664b02edc66866e98a31b)

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 Friday
15 October.

Note that the NEWS file hasn't been fully updated yet.

[Valgrind-users] trying to understand behavior with call indirect through plt

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

If I run the exact same version of my Valgrind based tool on the exact same
target binary but on different disk drives I get a different result.  I
understand that different block sizes on the two drives might cause
different paths through the C runtime, but I would expect the user program
to have the exact same results.

The difference appears to be the processing of the instruction (on AMD64):
 callq  400c50 <fputs@plt>

I understand how the plt/got code works in general, but I am curious as to
how Valgrind treats it.

I am using the trace-flags option to observe the program flow of control.
So the two program executions are basically matching until we get to the
second time the program calls fputs.  In one case, the next SB processed
starts with the instruction after the call.  In the other case, it appears
the indirect call sends us out into the middle of the clib routine
_IO_default_xsputn as that is the next SB processed.  Then the next SB after
that one is the instruction after the call as in the first case.

As my program is using Valgrind to do code instrumentation, the addition of
the extra  xsputn SB has a knock on effect that changes the program output.

I am assuming that previously translated SBs are 'skipped' in the
trace-flags output.  Is there an option to show  that SB <number> is being
executed again?  That is, show the complete flow of control for the program?
Assuming my program has not trashed Valgrind in some way, could it be
possible that _IO_default_xsputn is a portion of the code for fputs that was
not needed in one case do to the difference in disk block sizes?


Thank you,
Mark Roberts
UW PLSE group

Re: [Valgrind-users] Why valgrind can't see this error?

[Eric C. <Eri...@gi...>]

Hi John,

On 2021-09-03 6:53 p.m., John Reiser wrote:
> On 9/3/21 12:31 PM, Eric Chamberland wrote:
>> Hi,
>>
>> I have a simple test and valgrind seems to not see the error:
>>
>> cat fread.cc && clang++ -o fread fread.cc && valgrind ./fread
>> #include <iostream>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int argc, char ** argv){
>>      int lA {1};
>>      FILE * f = fopen ( argv[0] , "rb" );
>>      fread(&lA,2*sizeof(int),1,f);
>>      std::cout << "Hello: "<< lA << std::endl;
>>      return 0;
>> }
>
> This report is interesting only because it is a bad example:
> it does not specify what is the supposed error.
> If you don't say what you believe it is, then how are valgrind 
> developers to know?

Yes, indeed, sorry for not giving a good example!

>
> Besides, the "memcheck error" is covered in the valgrind FAQ.
> Look it up in paragraph "4.6.  Why doesn't Memcheck find ..."

Ok, thanks, the answer was there : 
https://valgrind.org/docs/manual/faq.html#faq.overruns

> The second and third errors are the logic errors of not checking
> the return value of fopen and fread.
> The fourth error is not documenting the expected invocation command line.
> The fifth error is not checking argc.
> The sixth error is not documenting the expected format of the input file.
> Are you sure that you really are a programmer?

I am happy with your answer, no need to dive into this: you helped 
someone! :)

Thanks again John!

Eric

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

-- 
Eric Chamberland, ing., M. Ing
Professionnel de recherche
GIREF/Université Laval
(418) 656-2131 poste 41 22 42

Re: [Valgrind-users] Very slow execution under Fedora 34

[Alvaro K. <ku...@gm...>]

Yes, I installed debuginfo to try gdb reverse-step.

The packages installed where: debuginfo-install glibc-2.33-20.fc34.x86_64
libgcc-11.2.1-1.fc34.x86_64 libstdc++-11.2.1-1.fc34.x86_64

On Mon, Sep 6, 2021 at 8:37 AM Mark Wielaard <ma...@kl...> wrote:

> Hi,
>
> On Sun, 2021-09-05 at 20:29 -0300, Alvaro Kuolas wrote:
> > I am running valgrind on my PC with dual boot Windows 10 and Fedora
> > 34.
> >
> > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2)
> > valgrind runs
> > in less than a second, but on Fedora 34 is very slow, several minutes
> > slow.
> >
> > On Fedora 34 it looks like the time spent is reading symbols.
>
> Do you have lots of debuginfo packages installed or is the
> DEBUGINFOD_URLS set? See https://fedoraproject.org/wiki/Debuginfod
>
> valgrind is fairly slow parsing all the DWARF information. But will
> happily use debuginfod to fetch more or use all debuginfo packages
> installed for any library you have installed.
>
> In your case it might be help unsetting DEBUGINFOD_URLS and looking
> trough the list of installed debuginfo packages and uninstall some (if
> I read your log it is probably libstdc++-debuginfo that takes a lot of
> time to parse.
>
> Cheers,
>
> Mark
>

Re: [Valgrind-users] Very slow execution under Fedora 34

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

Hi,

On Sun, 2021-09-05 at 20:29 -0300, Alvaro Kuolas wrote:
> I am running valgrind on my PC with dual boot Windows 10 and Fedora
> 34.
> 
> Running the same test on Ubuntu 20.04 (under Windows 10 WSL2)
> valgrind runs
> in less than a second, but on Fedora 34 is very slow, several minutes
> slow.
> 
> On Fedora 34 it looks like the time spent is reading symbols.

Do you have lots of debuginfo packages installed or is the
DEBUGINFOD_URLS set? See https://fedoraproject.org/wiki/Debuginfod

valgrind is fairly slow parsing all the DWARF information. But will
happily use debuginfod to fetch more or use all debuginfo packages
installed for any library you have installed.

In your case it might be help unsetting DEBUGINFOD_URLS and looking
trough the list of installed debuginfo packages and uninstall some (if
I read your log it is probably libstdc++-debuginfo that takes a lot of
time to parse.

Cheers,

Mark

Re: [Valgrind-users] Very slow execution under Fedora 34

[Alvaro K. <ku...@gm...>]

My program is very simple: they are exercises from a course about ADT
(Abstract Data Types).

On Sun, Sep 5, 2021 at 11:24 PM John Borland <
all...@gm...> wrote:

> if you have a lot of threads you can try the fair scheduler flag.
>
> On Sun, Sep 5, 2021, 8:59 PM John Reiser <jr...@bi...> wrote:
>
>> > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.
>> >
>> > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind
>> runs in less than a second, but on Fedora 34 is very slow, several minutes
>> slow.
>> >
>> > On Fedora 34 it looks like the time spent is reading symbols.
>> >
>> > This is the part that takes most of the time:
>> >
>> > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
>> > --23524--   Considering
>> /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
>> > --23524--   .. build-id is valid
>> > --23524--   Considering
>> /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
>> ..
>> > --23524--   .. build-id is valid
>> [[snip]]
>> >
>> > What could be the problem? GGC 11 perhaps?
>>
>> There have been some hints of trouble with the DWARF-5 symbol reader.
>> Thus a work-around might be to avoid DWARF-5 by using an older gcc.
>>
>> If you can, please run "perf record" and then "perf report",
>> and copy+paste (or attach) info into a Bug Report (see
>> https://valgrind.org).
>> Then post the bug link here with a teaser.
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Very slow execution under Fedora 34

[Alvaro K. <ku...@gm...>]

I opened a bug report

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

I have attached perf-record data

Thanks for your help!

On Sun, Sep 5, 2021 at 10:59 PM John Reiser <jr...@bi...> wrote:

> > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.
> >
> > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind
> runs in less than a second, but on Fedora 34 is very slow, several minutes
> slow.
> >
> > On Fedora 34 it looks like the time spent is reading symbols.
> >
> > This is the part that takes most of the time:
> >
> > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
> > --23524--   Considering
> /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
> > --23524--   .. build-id is valid
> > --23524--   Considering
> /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
> ..
> > --23524--   .. build-id is valid
> [[snip]]
> >
> > What could be the problem? GGC 11 perhaps?
>
> There have been some hints of trouble with the DWARF-5 symbol reader.
> Thus a work-around might be to avoid DWARF-5 by using an older gcc.
>
> If you can, please run "perf record" and then "perf report",
> and copy+paste (or attach) info into a Bug Report (see
> https://valgrind.org).
> Then post the bug link here with a teaser.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>