【发布时间】:2016-11-30 02:59:04
【问题描述】:
我已经为我正在使用的数据库基础架构编写了一个多线程压力测试,并且我正在尝试使用 callgrind 对其进行分析。该程序在 valgrind 之外完美执行并提供预期的结果。
但是,当在 valgrind --tool=callgrind 下运行时,程序会执行一小段时间,然后停止,valgrind 报告 Killed 作为它的最后一个输出到 stdout。
有没有办法让我确定 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 吗?还是您的内存不足并且内核正在杀死该进程?
-
@threadp callgrind 会增加显着的内存开销吗?我没有在我的应用程序中分配太多内存,并且在通常在内核中运行之前它从未耗尽内存?我将如何确定这一点?
-
在杀死发生后检查你的
dmesg输出。这不太可能是问题,但有可能。 -
dmesg输出中没有与我的进程或 valgrind 相关的任何内容
标签: c++ multithreading profiling valgrind callgrind