代码执行将分配所有内存，直到它可能在代码初始化时被OOMlinux杀死为止调试此类问题的想法？

问题描述

我在使用某些代码时遇到了一个非常奇怪的问题。我正在尝试调试在Linux集群上编译的C ++ / Fortran代码。运行它时，在屏幕上没有任何输出，并且代码崩溃。我可以从顶部看到我的应用程序启动并分配内存，直到用完（128GB）并被内核OOM杀死为止。我尝试使用调试器，并在main上设置了一个断点，但仍然得到相同的行为。因此，我假设错误发生在进入main之前，因此我认为它与静态/全局数据初始化或类初始化有关。我尝试了几种编译器优化选项，使用-O0时取得了一些成功，但是在其他任何优化级别下，它们都崩溃了。具有不同优化选项的不同行为向我表明，代码中还存在诸如未定义行为之类的问题，但我也不知道该如何解决。

我知道这个问题并不是理想的情况，我没有一个简单的示例。即使该代码在公共存储库中可用，也很难编译，并且您需要运行不公开的输入文件。

到目前为止，这是我设法做到的。我不知道如何解决此错误，因此任何想法或建议都将受到欢迎，我会尽力回答任何问题。

谢谢！

解决方法

第一步是用strace验证这不是迟来的execve故障。这种故障表现为在execve之后的立即信号，而在execve之后没有针对同一进程的任何系统调用。

发生这种情况是因为execve不是原子的：如果它已开始用新的过程映像替换当前过程映像，但此后失败，则不会返回错误（因为它可以返回到原始过程映像）消失了），而是用信号终止了该过程。信号随内核版本（SIGKILL或SIGSEGV，如果我没记错的话）而变化。如果发生这种情况，则意味着您的程序可能具有一些非常大的全局变量。它们应显示为带有LOAD的大型readelf -lW段和带有readelf -SW的大型数据段。

如果不是晚期execve失败，则希望程序初始化运行足够长的时间，以便您可以在调试器和^C下运行它，或将其发送给SIGINT，并获得回溯这种方式，看看它在做什么。如果这样不起作用，则可以在__libc_start_main上设置一个断点并逐步执行，直到它通过init函数指针调用主程序ELF构造函数。对于共享对象中的ELF构造函数，您需要在_dl_init上设置一个断点（对于将来的glibc版本，可能以glibc 2.33或2.34开头；它们将不再运行__libc_start_main中的主程序ELF构造函数）