Question

linux 下如何打开core dump文件开关

Answer 1

dump文件可以在程序crash时，方便我们查看程序crash的地方和上下文信息。在window下，要能生成dump文件，需要自己编写相应的代码。不过现在网上可以找到相应的代码，只要把它下载后然后加到自己的工程中去，就可以了！ 在linux下面就简单的许多。只要打开相应的开关，linux会自动在程序crash时生成相应的core文件。这个文件和window下的dump文件类似。 下面是简单的一些步骤： 1.查看当前是否已经打开了此开关 通过命令：ulimit -c 如果输出为 0 ，则代表没有打开。如果为unlimited则已经打开了,就没必要在做打开。 2.通过命令打开 ulimit -c unlimited .然后通过步骤1，可以监测是否打开成功。 3.如果你要取消，很简单：ulimit -c 0 就可以了 通过上面的命令修改后，一般都只是对当前会话起作用，当你下次重新登录后，还是要重新输入上面的命令，所以很麻烦。我们可以把通过修改 /etc/profile文件 来使系统每次自动打开。步骤如下： 1.首先打开/etc/profile文件 一般都可以在文件中找到 这句语句：ulimit -S -c 0 /dev/null 2&1.ok，根据上面的例子，我们只要把那个0 改为 unlimited 就ok了。然后保存退出。 2.通过source /etc/profile 使当期设置生效。 3.通过ulimit -c 查看下是否已经打开。 其实不光这个命令可以加入到/etc/profile文件中，一些其他我们需要每次登录都生效的都可以加入到此文件中，因为登录时linux都会加载此文件。比如一些环境变量的设置。 还有一种方法可以通过修改/etc/security/limits.conf文件来设置，这个方法没有试过，也是网上看到。不过上面两种就可以了！ 最后说一下生成core dump文件的位置，默认位置与可执行程序在同一目录下，文件名是core.***，其中***是一个数字。core dump文件名的模式保存在/proc/sys/kernel/core_pattern中，缺省值是core。通过以下命令可以更改core dump文件的位置(如希望生成到/tmp/cores目录下) echo “/tmp/cores/core” /proc/sys/kernel/core_pattern 设置完以后我们可以做个测试，写个程序，产生一个异常。然后看到当前目录会有个core*的文件。然后我们可以 gdb core。* 程序 进行调试。

Answer 2

查看 error log：

我们拿到了崩溃位置0xee36f1，如何找到与之相对的代码位置呢？

找台测试机，获取对应版本的安装包：

解压：

然后用 GDB 打开 mysqld：

在 0xee36f1 位置打一个断点：

我们可以看到，gdb 将崩溃位置的文件名和行号都打印出来，

剩下的事情，就可以交给开发工程师，按照这个崩溃堆栈来进行问题排查。

赠送章节

红框内的这串信息是什么？我们来解开看一下，

这段信息分为两段，"+0x71" 是一个偏移量，前面是一串文字，我们将文字解析出来：

可以看到前面这串文字是一个函数签名的编码，用 c++filt 还原编码以后，可以看到完整的函数签名。

红框内的这串信息的意思就是崩溃位置是 一个函数起始位置 + 偏移量。

我们大概可以猜到，这个 MySQL 的缺陷是在为 binlog 产生新的文件名时发生的。

小贴士：

函数起始位置 + 偏移量 是一种内存位置的表示方法，但该位置不一定是这个函数内的代码。

以本例来说，0xee36f1 这个位置，程序找到了就近的函数 generate_new_name 的起始位置，计算出有 0x71 这么多偏移，就表示成了 generate_new_name+0x71 这种形式。

但 0xee36f1 这个位置的代码，大概率是，但，不一定是 generate_new_name 这个函数内部的一段代码。

Answer 3

从接触unix开始就一直听到和遇到core dump，特别是刚学着使用C语言在AIX下编写程序的时候，core dump更是时不时就会不请自来。记得当时刚写应用的时候，提交程序时最怕的就是在运行过程时遇到core dump，对于银行核心系统，特别是使用静态应用进程，如果一个相对频繁一点的交易导致core dump，那么毫无疑问，除了赶紧定位错误改程序外，重启进程甚至无法争取到多少缓冲的时间来进行代码的更正和测试。而且往往导致core dump的，就是程序中一个小小的未注意到或者未测试到的一个疏忽。

虽然常常遇到core dump，不过很长时间内，都是出于知道这个名字，知道它导致的后果，知道一部分导致它出现的原因，其他的就都不甚了了了。说起来，就是自己太懒了，懒得看书......少壮不努力啊。看过一则统计，说60岁以上的老人，超过70%都后悔少壮不努力，不知统计的数据能否反映整个社会的情况。不过总的来说，这句古话还是有些道理的。大家不要学我。哈哈

core dump，翻译过来讲，就是核心转储。大致上就是指，如果由于应用错误，如浮点异常、指令异常等，操作系统将会转入内核的异常处理，向对应的进程发送特定的信号（SIGNAL），如果进程中没有对这些信号进行处理，就会转入默认的处理，core dump就是其中的一种。如果进程core dump，系统将会终止该进程，同时系统会产生core文件，以供调试使用。这个core文件其实就是内存的映像，即进程执行的时候内存的内容，也就是所谓的core dump。平常大家说某某进程core dump了，其实主要的意思就是说：某某进程因为错误而被系统自动终止了。

AIX上提供了dbx工具可以对core dump进行调试，协助定位引起core dump的代码。最普通的语法是：
dbx 应用名 core文件， 然后使用where命令来显示调试信息
一般来讲，根据工作中遇到的情况，dbx还是能够比较轻松的根据提示的内容来定位代码的。不过也有一些特殊情况时，dbx显示的调试信息过于模糊或者不直观，这个时候就只能根据经验来逐步定位了。有时定位起来会耗用相当长的时间。遇到这种情况时，使用日志文件，通过在代码中穿插多个写log的语句，也可以协助发现。因为进程core dump时，日志当然也中断了，根据日志在哪个代码行之后或之前中止了，可以有效缩小寻找的范围。甚至，在有些情况下，使用日志定位是唯一简便的方法了。

Answer 4

在 console 下， 用 gdb ELF CORE-FILE 方式来调试程序。