是否有可能valgrind报告我的程序正确运行的致命错误?

Is it possible that valgrind reports fatal errors of my program which runs correctly?

本文关键字：运行 致命错误 程序 有可能 valgrind 报告 我的 是否      更新时间：2023-10-16

当我运行我的程序时，或者当我用gdb运行它时，它似乎运行正确，没有错误，我得到了预期的输出。

但是当我通过valgrind ./program使用valgrind运行它时，它甚至没有走远。我得到一个VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -退出从一开始。valgrind输出对我没有任何帮助。我调用了一个子进程，但是valgrind没有遵循它。我尝试使用--trace-children=yes选项，但没有改变。

另一个问题:调用valgrind program和valgrind ./program之间有什么区别?

我得到的输出是: 
$ valgrind --tool=memcheck --trace-children=yes ./program
==2616== Memcheck, a memory error detector
==2616== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2616== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==2616== Command: ./program
==2616== 
Parent pid is 2616
Child pid is 2619
main() could not create fifo
--2619-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--2619-- si_code=2;  Faulting address: 0x400DFD;  sp: 0x403277b70
valgrind: the 'impossible' happened:
   Killed by fatal signal
==2619==    at 0x3802D33A: mash_colon_env (m_libcproc.c:195)
==2619==    by 0x3802D6FD: vgPlain_env_remove_valgrind_env_stuff (m_libcproc.c:254)
==2619==    by 0x3806EB7C: vgSysWrap_generic_sys_execve_before (syswrap-generic.c:2622)
==2619==    by 0x38068750: vgPlain_client_syscall (syswrap-main.c:1443)
==2619==    by 0x380651E9: handle_syscall (scheduler.c:895)
==2619==    by 0x38066D6A: vgPlain_scheduler (scheduler.c:1091)
==2619==    by 0x380763FC: run_a_thread_NORETURN (syswrap-linux.c:94)
sched status:
  running_tid=1
Thread 1: status = VgTs_Runnable
==2619==    at 0x567D957: execve (execve.c:60)
==2619==    by 0x567E1E8: execvpe (execvpe.c:151)
==2619==    by 0x400B2D: main (program2.cpp:34)

该错误表明您很可能在valgrind中遇到了错误。事实上，它已经被报告了(https://bugs.kde.org/show_bug.cgi?id=271582)，所以你应该把自己添加到这个错误中，以便与修复它的工作保持同步。

一般情况下，这样的"VALGRIND INTERNAL ERROR"消息应该在https://bugs.kde.org/enter_valgrind_bug.cgi上报告，确保您在程序中包含运行valgrind -v的完整输出。

你应该使用Valgrind "follow-fork-mode"子模式。这就是为什么Valgrind可能不会跟随您的子进程。

相关文章：