| Summary: | DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 (consts) and DW_OP_ opcode 0x92 (bregx) | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Andrea <andrea> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | cbs.gaoliang, malat, mark |
| Priority: | NOR | ||
| Version First Reported In: | 3.20.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | % valgrind --debug-dump=frames ./fails >& /tmp/frames.txt | ||
Same with highway:
% clang++-16 -o fails math_test4.cc -lhwy_contrib
% cat math_test4.cc
int main() {}
% clang++-16 -o fails math_test4.cc -lhwy_contrib
% valgrind ./fails
==3733364== Memcheck, a memory error detector
==3733364== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3733364== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3733364== Command: ./fails
==3733364==
--3733364-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92
valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree):
Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
host stacktrace:
==3733364== at 0x58040D44: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x58040E93: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x58040FFB: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x580C3BB7: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x580C3D53: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x580C91E3: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x5807A497: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x5806F613: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x5809E927: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x580AB983: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x5809AA1B: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x5809647F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x5809882F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0x580DFC5F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364== by 0xFFFFFFFFFFFFFFFF: ???
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable syscall 222 (lwpid 3733364)
==3733364== at 0x401AB6C: __mmap64 (mmap64.c:58)
==3733364== by 0x401AB6C: mmap (mmap64.c:46)
==3733364== by 0x40066F3: _dl_map_segments (dl-map-segments.h:139)
==3733364== by 0x40066F3: _dl_map_object_from_fd (dl-load.c:1268)
==3733364== by 0x40078BF: _dl_map_object (dl-load.c:2272)
==3733364== by 0x400243B: openaux (dl-deps.c:64)
==3733364== by 0x40012FB: _dl_catch_exception (dl-catch.c:237)
==3733364== by 0x40028EB: _dl_map_object_deps (dl-deps.c:232)
==3733364== by 0x4017A47: dl_main (rtld.c:1972)
==3733364== by 0x4014E8B: _dl_sysdep_start (dl-sysdep.c:140)
==3733364== by 0x4016273: _dl_start_final (rtld.c:497)
==3733364== by 0x4016273: _dl_start (rtld.c:584)
==3733364== by 0x401A193: (below main) (dl-start.S:30)
client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFF150
valgrind stack range: [0x1002CB8000 0x1002DB7FFF] top usage: 17968 of 1048576
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
The first issue seems to be because we cannot handle the CFI from this libamath.so library. For the second it isn't clear which library causes the issue. Could you rerun with -v ? (In reply to Mark Wielaard from comment #2) > The first issue seems to be because we cannot handle the CFI from this > libamath.so library. > For the second it isn't clear which library causes the issue. Could you > rerun with -v ? Sorry for being sloppy here. Here you: % valgrind -v ./fails ==284860== Memcheck, a memory error detector ==284860== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==284860== Using Valgrind-3.19.0-8d3c8034b8-20220411 and LibVEX; rerun with -h for copyright info ==284860== Command: ./fails ==284860== --284860-- Valgrind options: --284860-- -v --284860-- Contents of /proc/version: --284860-- Linux version 5.10.0-25-arm64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.191-1 (2023-08-16) --284860-- --284860-- Arch and hwcaps: ARM64, LittleEndian, v8 --284860-- Page sizes: currently 4096, max supported 65536 --284860-- Valgrind library directory: /usr/libexec/valgrind --284860-- Reading syms from /home/malat/pr110643/fails --284860-- Reading syms from /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 --284860-- Considering /usr/lib/debug/.build-id/e3/1f8e686f102995033b5b17cc829c67c7efbc90.debug .. --284860-- .. build-id is valid --284860-- Reading syms from /usr/libexec/valgrind/memcheck-arm64-linux --284860-- object doesn't have a symbol table --284860-- object doesn't have a dynamic symbol table --284860-- Scheduler: using generic scheduler lock implementation. --284860-- Reading suppressions file: /usr/libexec/valgrind/default.supp ==284860== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-284860-by-malat-on-??? ==284860== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-284860-by-malat-on-??? ==284860== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-284860-by-malat-on-??? ==284860== ==284860== TO CONTROL THIS PROCESS USING vgdb (which you probably ==284860== don't want to do, unless you know exactly what you're doing, ==284860== or are doing some strange experiment): ==284860== /usr/bin/vgdb --pid=284860 ...command... ==284860== ==284860== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==284860== /path/to/gdb ./fails ==284860== and then give GDB the following command ==284860== target remote | /usr/bin/vgdb --pid=284860 ==284860== --pid is optional if only one valgrind process is running ==284860== --284860-- REDIR: 0x401c080 (ld-linux-aarch64.so.1:strlen) redirected to 0x580bb9f4 (???) --284860-- REDIR: 0x401b7c0 (ld-linux-aarch64.so.1:strcmp) redirected to 0x580bba48 (???) --284860-- REDIR: 0x401b700 (ld-linux-aarch64.so.1:index) redirected to 0x580bba1c (???) --284860-- Reading syms from /usr/libexec/valgrind/vgpreload_core-arm64-linux.so --284860-- object doesn't have a symbol table --284860-- Reading syms from /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so --284860-- object doesn't have a symbol table --284860-- Reading syms from /usr/lib/aarch64-linux-gnu/libhwy_contrib.so.1.0.7 --284860-- object doesn't have a symbol table --284860-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92 valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. host stacktrace: ==284860== at 0x58040D44: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x58040E93: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x58040FFB: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x580C3BB7: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x580C3D53: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x580C91E3: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x5807A497: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x5806F613: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x5809E927: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x580AB983: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x5809AA1B: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x5809647F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x5809882F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0x580DFC5F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860== by 0xFFFFFFFFFFFFFFFF: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 222 (lwpid 284860) ==284860== at 0x401AB6C: __mmap64 (mmap64.c:58) ==284860== by 0x401AB6C: mmap (mmap64.c:46) ==284860== by 0x40066F3: _dl_map_segments (dl-map-segments.h:139) ==284860== by 0x40066F3: _dl_map_object_from_fd (dl-load.c:1268) ==284860== by 0x40078BF: _dl_map_object (dl-load.c:2272) ==284860== by 0x400243B: openaux (dl-deps.c:64) ==284860== by 0x40012FB: _dl_catch_exception (dl-catch.c:237) ==284860== by 0x40028EB: _dl_map_object_deps (dl-deps.c:232) ==284860== by 0x4017A47: dl_main (rtld.c:1972) ==284860== by 0x4014E8B: _dl_sysdep_start (dl-sysdep.c:140) ==284860== by 0x4016273: _dl_start_final (rtld.c:497) ==284860== by 0x4016273: _dl_start (rtld.c:584) ==284860== by 0x401A193: (below main) (dl-start.S:30) client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFF150 valgrind stack range: [0x1002CB8000 0x1002DB7FFF] top usage: 17968 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. where: malat@amdahl ~/pr110643 % dpkg -S /usr/lib/aarch64-linux-gnu/libhwy_contrib.so.1.0.7 libhwy1:arm64: /usr/lib/aarch64-linux-gnu/libhwy_contrib.so.1.0.7 malat@amdahl ~/pr110643 % apt-cache policy libhwy1:arm64 libhwy1: Installed: 1.0.7-7 Candidate: 1.0.7-7 Version table: *** 1.0.7-7 500 500 https://deb.debian.org/debian sid/main arm64 Packages 100 /var/lib/dpkg/status Thanks, so that is in libhwy_contrib.so.1.0.7 which is https://packages.debian.org/sid/libhwy1 and can be downloaded through http://ftp.debian.org/debian/pool/main/h/highway/libhwy1_1.0.7-7_arm64.deb Without an arm64 debian setup trying to unpack that and looking for the any DW_CFA expressions with suspecious DW_OP expressions might be helpful. Could you maybe attach the output of readelf --debug-dump=frames libhwy_contrib.so.1.0.7 ? grepping that output for DW_OP might also provide some clues. Actually we have valgrind --debug-dump=frames so if you could rerun with that option and attach the output that would also be helpful. Created attachment 161747 [details]
% valgrind --debug-dump=frames ./fails >& /tmp/frames.txt
(In reply to Mark Wielaard from comment #4) > Thanks, so that is in libhwy_contrib.so.1.0.7 which is > https://packages.debian.org/sid/libhwy1 and can be downloaded through > http://ftp.debian.org/debian/pool/main/h/highway/libhwy1_1.0.7-7_arm64.deb > > Without an arm64 debian setup trying to unpack that and looking for the any > DW_CFA expressions with suspecious DW_OP expressions might be helpful. Just fyi % curl -O http://ftp.debian.org/debian/pool/main/h/highway/libhwy1_1.0.7-7_arm64.deb % ar x libhwy1_1.0.7-7_arm64.deb % tar tvf data.tar.xz [...] -rw-r--r-- root/root 2295800 2023-09-15 11:47 ./usr/lib/aarch64-linux-gnu/libhwy_contrib.so.1.0.7 Thanks that makes clear what is going wrong.
The full expression is:
def_cfa_expression 10
[ 0] breg31 0
[ 2] bregx 46 0
[ 5] lit8
[ 6] mul
[ 7] plus_uconst 80
[ 9] plus
And we do indeed not handle DW_OP_bregx (0x92).
But since we do handle DW_OP_breg0 ... DW_OP_breg31 it shouldn't be too hard to handle DW_OP_bregx too (the difference is in how the register argument is part of the opcode in the first, but encoded as a uleb128 argument in the second.
See dwarfexpr_to_dag in coregrind/m_debuginfo/readdwarf.c (and somewhat identical code, that does handle DW_OP_bregx in evaluate_Dwarf3_Expr coregrind/m_debuginfo/d3basics.c.
I also recently encounted this problem when I ran pytorch with valgrind on arm64 platform.
I tried to make the following changes to coregrind/m_debuginfo/readwarf.c (the codebase is valgrind-3.21.0) that fixed the blocking problem in my environment, although I'm not quite sure if it's correct. For Mathieu Malaterre and others:
case DW_OP_breg0 ... DW_OP_breg31:
break;
// === BEGIN support DW_OP_bregx(0x92) ===
case DW_OP_bregx:
uw = (UWord)step_leb128U( &expr );
sw = step_leb128S( &expr );
ix = ML_(CfiExpr_Binop)( dst,
Cbinop_Add,
ML_(CfiExpr_DwReg)( dst, uw ),
ML_(CfiExpr_Const)( dst, (UWord)sw )
);
PUSH(ix);
if (ddump_frames)
VG_(printf)("DW_OP_bregx: %ld", sw);
break;
// === END support DW_OP_bregx(0x92) ===
case DW_OP_reg0 ... DW_OP_reg31:
……
Thanks, that implementation of DW_OP_bregx is almost literally the same as what I came up with. I also implemented DW_OP_consts, which was reported in comment #1. And DW_OP_const8s, DW_OP_const8u and DW_OP_constu since they are fairly similar and were also missing. commit 9dd5db3cb1c46c50d29bf11a495a77e2669b847a Author: Mark Wielaard <mark@klomp.org> Date: Mon Oct 2 00:37:24 2023 +0200 Implement DW_OP_{bregx,consts,const8s,const8u,constu} in dwarfexpr_to_dag readdwarf.c (dwarfexpr_to_dag) didn't hanle various DW_OP expressions causing Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode and errors m_debuginfo/readdwarf.c:2822 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. Implement DW_OP_bregx and DW_OP_consts as reported in bug #461074. Also add implementations for DW_OP_const8s, DW_OP_const8u and DW_OP constu. https://bugs.kde.org/show_bug.cgi?id=461074 |
Failed assertion on Nvidia Jetson when linking a program with both the ArmPL (Arm Performance Libraries) and Pthread libraries. TEST CODE #include <iostream> int main(int argc, char *argv[]) { std::cout << "Hello, world!" << std::endl; } BUILD LINE g++ -g -O0 main.cpp -L/mnt/data/opt/lib -larmpl -lpthread VALGRIND OUTPUT ==29524== Memcheck, a memory error detector ==29524== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==29524== Using Valgrind-3.20.0-5147d671e4-20221024 and LibVEX; rerun with -h for copyright info ==29524== Command: ./a.out ==29524== --29524-- Valgrind options: --29524-- -v --29524-- Contents of /proc/version: --29524-- Linux version 4.9.201-tegra (buildbrain@mobile-u64-p211-d7000) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Fri Jul 9 08:56:59 PDT 2021 --29524-- --29524-- Arch and hwcaps: ARM64, LittleEndian, v8 --29524-- Page sizes: currently 4096, max supported 65536 --29524-- Valgrind library directory: /mnt/data/opt/libexec/valgrind --29524-- Reading syms from /mnt/data/andreac/valgrind/minimal/a.out --29524-- Reading syms from /lib/aarch64-linux-gnu/ld-2.27.so --29524-- Considering /lib/aarch64-linux-gnu/ld-2.27.so .. --29524-- .. CRC mismatch (computed b15b924d wanted 3fdedb9a) --29524-- Considering /usr/lib/debug/lib/aarch64-linux-gnu/ld-2.27.so .. --29524-- .. CRC is valid --29524-- Reading syms from /mnt/data/opt/libexec/valgrind/memcheck-arm64-linux --29524-- object doesn't have a dynamic symbol table --29524-- Scheduler: using generic scheduler lock implementation. --29524-- Reading suppressions file: /mnt/data/opt/libexec/valgrind/default.supp ==29524== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-29524-by-andreac-on-??? ==29524== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-29524-by-andreac-on-??? ==29524== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-29524-by-andreac-on-??? ==29524== ==29524== TO CONTROL THIS PROCESS USING vgdb (which you probably ==29524== don't want to do, unless you know exactly what you're doing, ==29524== or are doing some strange experiment): ==29524== /mnt/data/opt/libexec/valgrind/../../bin/vgdb --pid=29524 ...command... ==29524== ==29524== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==29524== /path/to/gdb ./a.out ==29524== and then give GDB the following command ==29524== target remote | /mnt/data/opt/libexec/valgrind/../../bin/vgdb --pid=29524 ==29524== --pid is optional if only one valgrind process is running ==29524== --29524-- REDIR: 0x4017440 (ld-linux-aarch64.so.1:strlen) redirected to 0x580ddaf8 (vgPlain_arm64_linux_REDIR_FOR_strlen) --29524-- REDIR: 0x40171c0 (ld-linux-aarch64.so.1:strcmp) redirected to 0x580ddb4c (vgPlain_arm64_linux_REDIR_FOR_strcmp) --29524-- REDIR: 0x40170c0 (ld-linux-aarch64.so.1:index) redirected to 0x580ddb20 (vgPlain_arm64_linux_REDIR_FOR_index) --29524-- Reading syms from /mnt/data/opt/libexec/valgrind/vgpreload_core-arm64-linux.so --29524-- Reading syms from /mnt/data/opt/libexec/valgrind/vgpreload_memcheck-arm64-linux.so --29524-- Reading syms from /mnt/data/opt/lib/libarmpl.so --29524-- Reading syms from /lib/aarch64-linux-gnu/libpthread-2.27.so --29524-- Considering /usr/lib/debug/.build-id/91/7e5291593df1ff1ac5d4db7309660570909a5d.debug .. --29524-- .. build-id is valid --29524-- Reading syms from /lib/aarch64-linux-gnu/libc-2.27.so --29524-- Considering /lib/aarch64-linux-gnu/libc-2.27.so .. --29524-- .. CRC mismatch (computed b0b5496f wanted a703a76c) --29524-- Considering /usr/lib/debug/lib/aarch64-linux-gnu/libc-2.27.so .. --29524-- .. CRC is valid ==29524== WARNING: new redirection conflicts with existing -- ignoring it --29524-- old: 0x06ad8e00 (memalign ) R-> (1011.0) 0x0484c844 memalign --29524-- new: 0x06ad8e00 (memalign ) R-> (1017.0) 0x0484c804 aligned_alloc ==29524== WARNING: new redirection conflicts with existing -- ignoring it --29524-- old: 0x06ad8e00 (memalign ) R-> (1011.0) 0x0484c844 memalign --29524-- new: 0x06ad8e00 (memalign ) R-> (1017.0) 0x0484c7c4 aligned_alloc ==29524== WARNING: new redirection conflicts with existing -- ignoring it --29524-- old: 0x06ad8e00 (memalign ) R-> (1011.0) 0x0484c844 memalign --29524-- new: 0x06ad8e00 (memalign ) R-> (1017.0) 0x0484c804 aligned_alloc ==29524== WARNING: new redirection conflicts with existing -- ignoring it --29524-- old: 0x06ad8e00 (memalign ) R-> (1011.0) 0x0484c844 memalign --29524-- new: 0x06ad8e00 (memalign ) R-> (1017.0) 0x0484c7c4 aligned_alloc --29524-- Reading syms from /mnt/data/opt/lib/libamath.so --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 --29524-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x11 valgrind: m_debuginfo/readdwarf.c:2822 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. host stacktrace: ==29524== at 0x5805274C: show_sched_status_wrk (m_libcassert.c:406) ==29524== by 0x5805287B: report_and_quit (m_libcassert.c:477) ==29524== by 0x580529DF: vgPlain_assert_fail (m_libcassert.c:543) ==29524== by 0x580E7A03: copy_convert_CfiExpr_tree (readdwarf.c:2822) ==29524== by 0x580E7DBF: summarise_context.isra.19 (readdwarf.c:2382) ==29524== by 0x580EE75F: run_CF_instructions (readdwarf.c:4009) ==29524== by 0x580EE75F: vgModuleLocal_read_callframe_info_dwarf3 (readdwarf.c:4565) ==29524== by 0x58096627: vgModuleLocal_read_elf_debug_info (readelf.c:3510) ==29524== by 0x5808B757: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:969) ==29524== by 0x5808B757: vgPlain_di_notify_mmap (debuginfo.c:1435) ==29524== by 0x580BFEA3: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2466) ==29524== by 0x580CE313: vgSysWrap_arm64_linux_sys_mmap_before (syswrap-arm64-linux.c:311) ==29524== by 0x580BA6D3: vgPlain_client_syscall (syswrap-main.c:2239) ==29524== by 0x580B67A7: handle_syscall (scheduler.c:1211) ==29524== by 0x580B869B: vgPlain_scheduler (scheduler.c:1529) ==29524== by 0x5810D6DB: thread_wrapper (syswrap-linux.c:102) ==29524== by 0x5810D6DB: run_a_thread_NORETURN (syswrap-linux.c:155) ==29524== by 0xFFFFFFFFFFFFFFFF: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 222 (lwpid 29524) ==29524== at 0x4016D44: mmap (mmap64.c:59) ==29524== by 0x4005627: _dl_map_segments (dl-map-segments.h:94) ==29524== by 0x4005627: _dl_map_object_from_fd (dl-load.c:1181) ==29524== by 0x4007C5F: _dl_map_object (dl-load.c:2460) ==29524== by 0x400BCE7: openaux (dl-deps.c:63) ==29524== by 0x4015A53: _dl_catch_exception (dl-error-skeleton.c:196) ==29524== by 0x400C057: _dl_map_object_deps (dl-deps.c:249) ==29524== by 0x40037EF: dl_main (rtld.c:1726) ==29524== by 0x4014D6F: _dl_sysdep_start (dl-sysdep.c:253) ==29524== by 0x40018C3: _dl_start_final (rtld.c:414) ==29524== by 0x4001B47: _dl_start (rtld.c:523) ==29524== by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so) client stack range: [0x1FFEFFD000 0x1FFF000FFF] client SP: 0x1FFEFFEB00 valgrind stack range: [0x1002EBC000 0x1002FBBFFF] top usage: 17056 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. SYSTEM INFO: Linux jetson 4.9.201-tegra #1 SMP PREEMPT Fri Jul 9 08:56:59 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux gcc version 7.5.0 valgrind version 3.20.0 ArmPL version 21.1_Ubuntu-18.04_gcc-7.5