本文介绍了最小核心转储(仅堆栈跟踪+当前帧)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我可以配置进入Linux核心转储的内容吗?我想获得像Windows迷你转储(应用程序崩溃时有关栈帧的最少信息)之类的内容。我知道你可以使用 ulimit 设置核心文件的最大大小,但是这不允许我控制内核中的内容(即,如果我设置限制为64kb,它会转储堆栈的最后16页)。



另外,我想以程序化的方式设置它(从代码), 如果可能的话。
我查看了 man core 提到的 / proc / PID / coredump_filter 文件,但似乎为了我的目的,它太粗粒了。



为了提供一个上下文:我需要很小的核心文件,原因很多:我需要通过网络收集它们,数千)客户;此外,这些是带有少量SD卡的嵌入式设备,以及用于网络连接的GPRS调制解调器。因此,大于200k的任何内容都是没有问题的。编辑:我正在运行Linux 2.6.24的嵌入式设备上工作。处理器是PowerPC。不幸的是,powerpc-linux目前在触摸板中不支持 ,所以google breakpad不是一个选项

我以两种方式解决了这个问题:


  1. 我为SIGSEGV安装了一个信号处理程序,使用backtrace / backtrace_symbols来打印堆栈跟踪。我用-rdynamic编译我的代码,所以即使在剥离调试信息后,我仍然使用有意义的名称进行回溯(同时保持可执行文件足够紧凑)。

    我剥离了调试信息并将其放入单独的文件,我将它存储在安全的地方,使用 strip ;从那里,我将使用 add22line 和从回溯(地址)保存的信息来了解问题发生的位置。这种方式我只需要存储几个字节。
  2. 或者,我发现我可以使用/ proc / self / coredump_filter来转储没有内存(将其内容设置为0):只有线程和proc信息,寄存器,栈跟踪等都保存在内核中。请参阅



maydump ()函数)。



现在,我对2种解决方案感到非常满意(比没有更好。 )我的下一步行动是:


Can I configure what goes into a core dump on Linux? I want to obtain something like the Windows mini-dumps (minimal information about the stack frame when the app crashed). I know you can set a max size for the core files using ulimit, but this does not allow me to control what goes inside the core (i.e. there is no guarantee that if I set the limit to 64kb it will dump the last 16 pages of the stack, for example).

Also, I would like to set it in a programmatic way (from code), if possible.I have looked at the /proc/PID/coredump_filter file mentioned by man core, but it seems too coarse grained for my purposes.

To provide a little context: I need tiny core files, for multiple reasons: I need to collect them over the network, for numerous (thousands) of clients; furthermore, these are embedded devices with little SD cards, and GPRS modems for the network connection. So anything above ~200k is out of question.

EDIT: I am working on an embedded device which runs linux 2.6.24. The processor is PowerPC. Unfortunately, powerpc-linux is not supported in breakpad at the moment, so google breakpad is not an option

解决方案

I have "solved" this issue in two ways:

  1. I installed a signal handler for SIGSEGV, and used backtrace/backtrace_symbols to print out the stack trace. I compiled my code with -rdynamic, so even after stripping the debug info I still get a backtrace with meaningful names (while keeping the executable compact enough).
    I stripped the debug info and put it in a separate file, which I will store somewhere safe, using strip; from there, I will use add22line with the info saved from the backtrace (addresses) to understand where the problem happened. This way I have to store only a few bytes.
  2. Alternatively, I found I could use the /proc/self/coredump_filter to dump no memory (setting its content to "0"): only thread and proc info, registers, stacktrace etc. are saved in the core. See more in this answer

I still lose information that could be precious (global and local variable(s) content, params..). I could easily figure out which page(s) to dump, but unfortunately there is no way to specify a "dump-these-pages" for normal core dumps (unless you are willing to go and patch the maydump() function in the kernel).

For now, I'm quite happy with there 2 solutions (it is better than nothing..) My next moves will be:

  • see how difficult would be to port Breakpad to powerpc-linux: there are already powerpc-darwin and i386-linux so.. how hard can it be? :)
  • try to use google-coredumper to dump only a few pages around the current ESP (that should give me locals and parameters) and around "&some_global" (that should give me globals).

这篇关于最小核心转储(仅堆栈跟踪+当前帧)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-19 14:43