当OOM杀手杀死该过程时,调试外撞车事故发生了吗?
在找到解决方案后将其发布为Q&
A。添加信号处理程序并不能阻止这种情况,因此它可能是sigterm
。由于该过程被杀死,调试器无法提供回溯。
从迹象来看,在高度记忆使用之前,它可能与OOM杀手有关。完全禁用OOM杀手,
sudo sh -c "echo 2 > /proc/sys/vm/overcommit_memory"
导致许多程序崩溃。
可以做些什么来找到问题的来源,例如,返回跟踪,指示在哪里使用了过多的内存?
Posted as Q&A after finding a solution.
Working on a simulation code base on Linux, allocating memory succeeds, but later process gets killed by an external signal. Adding a signal handler does not prevent this, so it is presumably a SIGTERM
. Since the process is killed, a debugger cannot provide a backtrace.
Judging by the signs, and preceding high memory usage, it is probably related to the OOM killer. Outright disabling the OOM Killer with
sudo sh -c "echo 2 > /proc/sys/vm/overcommit_memory"
resulted in many programs crashing.
What can be done to find the source of the issue, e.g. to get a backtrace indicating where too much memory is being used?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我在开放式Suse 15.2上观察了这个问题,当时在Fortran程序中调试崩溃时。很明显,这是从测试仪的描述中的一个失调的问题,但是在我的系统上,我只会
在终端上看到,而没有发射回溯。
在我的系统上,问题的来源是将虚拟内存设置为“无限”,如通过为
虚拟内存设置最大值,例如
通过使模拟程序从
分配,或用回溯*崩溃*用于未经处理的失败分配(例如,来自表达式中的临时变量
cmplx(transpose(some_larger_than_exped_matrix))
)。*假设可执行文件是由支持回溯(编译器依赖性)的支持,请通过调试器运行,...
I observed this issue on Open Suse 15.2 when debugging a crash in a Fortran program. It was clear that it was an out-of-memory issue from the description of the tester, but on my system I would simply see
on the terminal, with no traceback being emitted.
On my system, the source of the issue turned out to be that virtual memory was set to "unlimited", as seen by
Setting a maximum for the virtual memory, e.g.
resolved the issue by making the simulation program return an error code from
ALLOCATE
, or crash with a backtrace* for unhandled failed allocations (e.g. from temporary variables in the expressioncmplx(transpose(some_larger_than_expected_matrix))
).* Assuming that the executable was compiled with support for backtraces (compiler-dependent), run through a debugger, ...