从进程内部转储Linux核心文件的好方法是什么?

我们有一个服务器(用C和C ++编写),它目前捕获一个SEGV并将一些内部信息转储到一个文件中。 我想生成一个核心文件,并在抓到SEGV的时候把它写到磁盘上,所以我们的支持代表和客户不需要大惊小怪,然后等待崩溃再次发生,以便得到一个核心文件。 过去我们使用了中止函数,但是它受限于规则,并没有帮助。

我们有一些遗留代码读取/ proc / pid / map并手动生成一个核心文件,但它已经过时了,看起来并不是很便携(例如,我猜测它不适用于我们的64位编译)。 在Linux进程中生成和转储核心文件的最佳方式是什么?

Solutions Collecting From Web of "从进程内部转储Linux核心文件的好方法是什么?"

Google有一个库,用于从一个名为google-coredumper的运行过程中生成coredumps 。 这应该忽略ulimit和其他机制。

生成核心文件的调用文档就在这里 。 根据文档,在信号处理程序中生成一个核心文件似乎是可行的,尽管不能保证一直工作。

我看到了pmbrett的帖子,并认为“嘿,这很酷”,但无法在我的系统(Gentoo)的任何地方找到该实用程序。

所以我做了一些刺激,发现GDB有这个选项。

gdb --pid=4049 --batch -ex gcore 

似乎为我工作得很好。

它不是非常有用,因为它陷阱了当时正在使用的最低功能,但它仍然做了一个很好的工作之外(没有内存限制,倾倒了一个Firefox进程的350M快照)

尝试使用Linux命令gcore

用法:gcore [-o filename] pid

您需要使用system(或exec)和getpid()来构建正确的命令行,以便在流程中调用它

一些可能的解决方案:处理这种情况的方式:

  1. 修复ulimit!
  2. 接受你没有得到一个核心文件并运行gdb,脚本做一个“线程都应用bt”SIGSEGV
  3. 接受你没有得到核心文件,并从应用程序中获取堆栈跟踪。 程序文章中的栈回溯是相当古老的,但现在也应该是可能的。

您也可以使用setrlimit(2)从程序中更改ulimit()。 像ulimit shell命令一样,这可以降低限制,也可以像硬限制那样尽可能地提高限制。 在启动setrlimit()允许核心转储,你很好。

例如,我假设你有一个捕获SEGV的信号处理程序,并且执行诸如打印消息和调用_exit()之类的操作。 (否则,你会有一个核心文件在第一位!)你可以做下面的事情。

 void my_handler(int sig) { ... if (wantCore_ && !fork()) { setrlimit(...); // ulimit -Sc unlimited sigset(sig, SIG_DFL); // reset default handler raise(sig); // doesn't return, generates a core file } _exit(1); } 

系统(“杀-6”)

如果你还在找东西,我会试试看

使用backtrace和backtrace_symbols glibc调用来获取跟踪,请记住,backtrace_symbols在内部使用malloc,如果发生堆损坏,可能会失败。