gpt4 book ai didi

c++ - 如何确定 valgrind/callgrind 终止进程的原因

转载 作者:行者123 更新时间:2023-11-28 02:03:07 25 4
gpt4 key购买 nike

我已经为我正在使用的数据库基础架构编写了一个多线程压力测试,我正在尝试使用 callgrind 对其进行概要分析。该程序在 valgrind 之外完美执行并提供预期结果。

但是,当在 valgrind --tool=callgrind 下运行时,程序会执行一小段时间,然后停止,valgrind 报告 Killed 最后一次输出到标准输出。

有没有办法让我确定为什么 valgrind 终止了我的任务?


在遵循 phd 的建议后:它确实被 valgrind --tool=none 杀死了,但是,我不完全确定如何分析我收到的消息,似乎有我的线程中有很多 sigvgkill 信号。第一个实例在这里:

--13713:1:syswrap- run_a_thread_NORETURN(tid=104): pre-thread_wrapper
--> [pre-success] Success(0x0:0x365c)--13713:1:syswrap- thread_wrapper(tid=104): entry
SYSCALL[13713,104](311) sys_set_robust_list ( 0x4f213be0, 12 )[sync] --> Success(0x0:0x0)
SYSCALL[13713,104](240) sys_futex ( 0xbeaf348, 128, 2, 0x0, 0x0 ) --> [async] ...
--13713-- async signal handler: signal=13, tid=32, si_code=0
--13713-- interrupted_syscall: tid=32, ip=0x380b197c, restart=False, sres.isErr=True, sres.val=32
--13713-- completed, but uncommitted: committing
--13713:1:gdbsrv VG core calling VG_(gdbserver_report_signal) vki_nr 13 SIGPIPE gdb_nr 13 SIGPIPE tid 32
--13713:1:gdbsrv not connected => pass
--13713-- delivering signal 13 (SIGPIPE):0 to thread 32
--13713-- delivering 13 (code 0) to default handler; action: terminate
==13713==

最佳答案

据我所知,valgrind 不会用这么少的东西杀死一个程序冗长为“杀死”。这样的事情看起来更像是来自另一个进程的杀戮。

尽管如此,您可以尝试多种方法来调查您的程序行为的原因在 valgrind 下与 native 不同:

  1. 首先在 valgrind --tool=none 下运行它。这是更快的工具(什么都不做)。然后您可以查看您的程序是否按预期运行。如果没有,则使用额外的 valgrind 内部跟踪运行,例如

    --tool=none -v -v -v -d -d -d --trace-syscalls=yes --trace-signals=yes

    跟踪可能会提供有关它为何中止/被杀死的线索。

  2. --tool=memcheck--tool=helgrind 下运行它(同样,如果崩溃,您可以运行更多跟踪)。

  3. 最后,--tool=callgrind + 更多跟踪,如果上面没有还要澄清。

关于c++ - 如何确定 valgrind/callgrind 终止进程的原因,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38590262/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com