日志简介:
# valgrind --error-limit=no --leak-check=full --tool=memcheck /mnt/aarch64/ld-linux-aarch64.so.1 ./program
==12104== Memcheck, a memory error detector
==12104== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12104== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==12104== Command: /mnt/aarch64/ld-linux-aarch64.so.1 ./program
==12104==
vex: priv/host_arm64_defs.c:2796 (genSpill_ARM64): Assertion `offsetB < 4096' failed.
vex storage: T total 4207069920 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
host stacktrace:
==12104== at 0x5803F488: show_sched_status_wrk (m_libcassert.c:406)
==12104== by 0x5803F5C7: report_and_quit (m_libcassert.c:477)
==12104== by 0x5803F7FB: panic (m_libcassert.c:553)
==12104== by 0x5803F7FB: vgPlain_core_panic_at (m_libcassert.c:558)
==12104== by 0x5803F81F: vgPlain_core_panic (m_libcassert.c:563)
==12104== by 0x5805481B: failure_exit (m_translate.c:761)
==12104== by 0x5811E043: vex_assert_fail (main_util.c:245)
==12104== by 0x5817A897: genSpill_ARM64 (host_arm64_defs.c:2796)
==12104== by 0x58172217: spill_vreg (host_generic_reg_alloc3.c:338)
==12104== by 0x5817324F: doRegisterAllocation_v3 (host_generic_reg_alloc3.c:1280)
==12104== by 0x5811CD97: libvex_BackEnd (main_main.c:1133)
==12104== by 0x5811CD97: LibVEX_Translate (main_main.c:1236)
==12104== by 0x58056FCB: vgPlain_translate (m_translate.c:1830)
==12104== by 0x58092A27: handle_chain_me (scheduler.c:1169)
==12104== by 0x580954A7: vgPlain_scheduler (scheduler.c:1514)
==12104== by 0x580D8E8F: thread_wrapper (syswrap-linux.c:101)
==12104== by 0x580D8E8F: run_a_thread_NORETURN (syswrap-linux.c:154)
==12104== by 0x580D916F: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:328)
==12104== by 0x580A68D3: ??? (in /mnt/aarch64/lib/valgrind/memcheck-arm64-linux)
sched status:
running_tid=3
我想知道valgrind的重置输出在报告上述错误时是否仍然有意义，可以指出程序中的内存泄漏。the 'impossible' happened: LibVEX called failure_exit())
更新:当程序运行时，我可以看到许多堆栈序列，例如:
Thread 1: status = VgTs_WaitSys syscall 98 (lwpid 12168)
==12168== at 0x6E85274: syscall (in /lib/libc-2.31.so)
==12168== by 0x6B99FF3: std::__atomic_futex_unsigned_base
...
Thread 2:
...
一般来说，如果Valgrind报告了一些错误，然后遇到内部错误，那么这些初始报告应该是有效的。
对于您所显示的消息，第一个报告是与ARM aarch64 CPU虚拟化相关的内部错误。这只对Valgrind开发者有用。
尝试使用-d -v运行Valgrind。将会有很多输出，但是您应该看到
syswrap- run_a_thread_NORETURN(tid=1): pre-thread_wrapper是客户机可执行文件- 加载gdbsrv消息 当客户机启动代码调用ld.so来加载共享库时，REDIR和mallocrf/hashtable消息的混合
我不知道您从哪里获得后续跟踪-可能是跟踪选项，更可能是从断言。