点击上方“程序员大咖”，选择“置顶公众号”
关键时刻，第一时间送达！
先不说楚枫的这般年纪，能够踏入元武一重说明了什么，最主要的是，楚枫在刚刚踏入核心地带时，明明只是灵武七重，而在这两个月不到的时间，连跳两重修为，又跳过一个大境界，踏入了元武一重，这般进步速度，简直堪称变态啊。
“这楚枫不简单，原来是一位天才，若是让他继续成长下去，绝对能成为一号人物，不过可惜，他太狂妄了，竟与龚师兄定下生死约战，一年时间，他再厉害也无法战胜龚师兄。”有人认识到楚枫的潜力后，为楚枫感到惋惜。
“哼，何须一年，此子今日就必败，巫九与龚师兄关系甚好，早就看他不顺眼了，如今他竟敢登上生死台挑战巫九，巫九岂会放过他？”但也有人认为，楚枫今日就已是在劫难逃。
“何人挑战老子？”就在这时，又是一声爆喝响起，而后一道身影自人群之中掠出，最后稳稳的落在了比斗台上。
这位身材瘦弱，身高平平，长得那叫一个猥琐，金钩鼻子蛤蟆眼，嘴巴一张牙带色儿，说话臭气能传三十米，他若是当面对谁哈口气，都能让那人跪在地上狂呕不止。
不过别看这位长得不咋地，他在核心地带可是鼎鼎有名，剑道盟创建者，青龙榜第九名，正是巫九是也。
“你就是巫九？”楚枫眼前一亮，第一次发现，世间还有长得如此奇葩的人。
巫九鼻孔一张，大嘴一咧，拍着那干瘪的肚子，得意洋洋的道：“老子就是巫九，你挑战老子？”
“不是挑战你，是要宰了你。”楚枫冷声笑道。
“好，老子满足你这个心愿，长老，拿张生死状来，老子今日在这里了解了这小子。”巫九扯开嗓子，对着下方吼了一声。
如果他对内门长老这么说话，也就算了，但是敢这么跟核心长老说话的，他可真是算作胆肥的，就连许多核心弟子，都是倒吸了一口凉气，心想这楚枫够狂，想不到这巫九更狂。
不过最让人无言的就是，巫九话音落下不久，真有一位核心长老自人群走出，缓缓得来到了比斗台上，左手端着笔墨，右手拿着生死状，来到了巫九的身前。
“我去，这巫九什么身份，竟能这般使唤核心长老？”有人吃惊不已，那长老修为不低，乃是元武七重，比巫九还要高两个层次，但却这般听巫九的话，着实让人吃惊不已。
“这你就不知道了吧，巫九在前些时日，拜了钟离长老为师尊，已正式得到钟离长老的亲传。”有人解释道。
“钟离长老？可是那位性情古怪的钟离一护？”
“没错，就是他。”
“天哪，巫九竟然拜入了他的门下？”
人们再次大吃一惊，那钟离一护在青龙宗可是赫赫有名，若要是论其个人实力，在青龙宗内绝对能够排入前三，连护宗六老单打独斗都不会是他的对手。
只不过那钟离一护，如同诸葛青云一样，也是一位客卿长老，所以在青龙宗内只是挂个头衔，什么事都不管，更别说传授宗内弟子技艺了，如今巫九竟然能拜入他老人家门下，着实让人羡慕不已。
“恩怨生死台，的确可以决斗生死，但必须要有所恩怨，你们两个人，可有恩怨？”那位长老开口询问道。
本周工作中，我花了整整一周的时间来尝试调试一个段错误。我以前从来没有这样做过，我花了很长时间才弄清楚其中涉及的一些基本事情（获得核心转储、找到导致段错误的行号）。于是便有了这篇博客来解释如何做那些事情！
在看完这篇博客后，你应该知道如何从“哦，我的程序出现段错误，但我不知道正在发生什么”到“我知道它出现段错误时的堆栈、行号了！ ”。
什么是段错误？
“段错误segmentation fault”是指你的程序尝试访问不允许访问的内存地址的情况。这可能是由于：
试图解引用空指针（你不被允许访问内存地址 0）；
试图解引用其他一些不在你内存（LCTT 译注：指不在合法的内存地址区间内）中的指针；
一个已被破坏并且指向错误的地方的 C++ 虚表指针C++ vtable pointer，这导致程序尝试执行没有执行权限的内存中的指令；
其他一些我不明白的事情，比如我认为访问未对齐的内存地址也可能会导致段错误（LCTT 译注：在要求自然边界对齐的体系结构，如 MIPS、ARM 中更容易因非对齐访问产生段错误）。
这个“C++ 虚表指针”是我的程序发生段错误的情况。我可能会在未来的博客中解释这个，因为我最初并不知道任何关于 C++ 的知识，并且这种虚表查找导致程序段错误的情况也是我所不了解的。
但是！这篇博客后不是关于 C++ 问题的。让我们谈论的基本的东西，比如，我们如何得到一个核心转储？
运行 valgrind
我发现找出为什么我的程序出现段错误的最简单的方式是使用 valgrind：我运行
valgrind -v your-program
这给了我一个故障时的堆栈调用序列。 简洁！
但我想也希望做一个更深入调查，并找出些 valgrind 没告诉我的信息！ 所以我想获得一个核心转储并探索它。
如何获得一个核心转储
核心转储core dump是您的程序内存的一个副本，并且当您试图调试您的有问题的程序哪里出错的时候它非常有用。
当您的程序出现段错误，Linux 的内核有时会把一个核心转储写到磁盘。 当我最初试图获得一个核心转储时，我很长一段时间非常沮丧，因为 – Linux 没有生成核心转储！我的核心转储在哪里？
这就是我最终做的事情：
在启动我的程序之前运行 ulimit -c unlimited
运行 sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
ulimit：设置核心转储的最大尺寸
ulimit -c 设置核心转储的最大尺寸。 它往往设置为 0，这意味着内核根本不会写核心转储。 它以千字节为单位。 ulimit 是按每个进程分别设置的 —— 你可以通过运行 cat /proc/PID/limit 看到一个进程的各种资源限制。
例如这些是我的系统上一个随便一个 Firefox 进程的资源限制：
内核在决定写入多大的核心转储文件时使用软限制soft limit（在这种情况下，max core file size = 0）。 您可以使用 shell 内置命令 ulimit（ulimit -c unlimited） 将软限制增加到硬限制hard limit。
kernel.core_pattern：核心转储保存在哪里
kernel.core_pattern 是一个内核参数，或者叫 “sysctl 设置”，它控制 Linux 内核将核心转储文件写到磁盘的哪里。
内核参数是一种设定您的系统全局设置的方法。您可以通过运行 sysctl -a 得到一个包含每个内核参数的列表，或使用 sysctl kernel.core_pattern 来专门查看 kernel.core_pattern 设置。
所以 sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t 将核心转储保存到目录 /tmp 下，并以 core 加上一系列能够标识（出故障的）进程的参数构成的后缀为文件名。
如果你想知道这些形如 %e、%p 的参数都表示什么，请参考 man core。
有一点很重要，kernel.core_pattern 是一个全局设置 —— 修改它的时候最好小心一点，因为有可能其它系统功能依赖于把它被设置为一个特定的方式（才能正常工作）。
kernel.core_pattern 和 Ubuntu
默认情况下在 ubuntu 系统中，kernel.core_pattern 被设置为下面的值：
$ sysctl kernel.core_pattern
kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P
这引起了我的迷惑（这 apport 是干什么的，它对我的核心转储做了什么？）。以下关于这个我了解到的：
Ubuntu 使用一种叫做 apport 的系统来报告 apt 包有关的崩溃信息。
设定 kernel.core_pattern=|/usr/share/apport/apport %p %s %c %d %P 意味着核心转储将被通过管道送给 apport 程序。
apport 的日志保存在文件 /var/log/apport.log 中。
apport 默认会忽略来自不属于 Ubuntu 软件包一部分的二进制文件的崩溃信息
我最终只是跳过了 apport，并把 kernel.core_pattern 重新设置为 sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t，因为我在一台开发机上，我不在乎 apport 是否工作，我也不想尝试让 apport 把我的核心转储留在磁盘上。
现在你有了核心转储，接下来干什么？
好的，现在我们了解了 ulimit 和 kernel.core_pattern ，并且实际上在磁盘的 /tmp 目录中有了一个核心转储文件。太好了！接下来干什么？我们仍然不知道该程序为什么会出现段错误！
下一步将使用 gdb 打开核心转储文件并获取堆栈调用序列。
从 gdb 中得到堆栈调用序列
你可以像这样用 gdb 打开一个核心转储文件：
$ gdb -c my_core_file
接下来，我们想知道程序崩溃时的堆栈是什么样的。在 gdb 提示符下运行 bt 会给你一个调用序列backtrace。在我的例子里，gdb 没有为二进制文件加载符号信息，所以这些函数名就像 “??????”。幸运的是，（我们通过）加载符号修复了它。
下面是如何加载调试符号。
symbol-file /path/to/my/binary
sharedlibrary
这从二进制文件及其引用的任何共享库中加载符号。一旦我这样做了，当我执行 bt 时，gdb 给了我一个带有行号的漂亮的堆栈跟踪！
如果你想它能工作，二进制文件应该以带有调试符号信息的方式被编译。在试图找出程序崩溃的原因时，堆栈跟踪中的行号非常有帮助。:)
查看每个线程的堆栈
通过以下方式在 gdb 中获取每个线程的调用栈！
thread apply all bt full
gdb + 核心转储 = 惊喜
如果你有一个带调试符号的核心转储以及 gdb，那太棒了！您可以上下查看调用堆栈（LCTT 译注：指跳进调用序列不同的函数中以便于查看局部变量），打印变量，并查看内存来得知发生了什么。这是最好的。
如果您仍然正在基于 gdb 向导来工作上，只打印出栈跟踪与bt也可以。 :)
ASAN
另一种搞清楚您的段错误的方法是使用 AddressSanitizer 选项编译程序（“ASAN”，即 $CC -fsanitize=address）然后运行它。 本文中我不准备讨论那个，因为本文已经相当长了，并且在我的例子中打开 ASAN 后段错误消失了，可能是因为 ASAN 使用了一个不同的内存分配器（系统内存分配器，而不是 tcmalloc）。
在未来如果我能让 ASAN 工作，我可能会多写点有关它的东西。（LCTT 译注：这里指使用 ASAN 也能复现段错误）
从一个核心转储得到一个堆栈跟踪真的很亲切！
这个博客听起来很多，当我做这些的时候很困惑，但说真的，从一个段错误的程序中获得一个堆栈调用序列不需要那么多步骤：
试试用 valgrind
如果那没用，或者你想要拿到一个核心转储来调查：
确保二进制文件编译时带有调试符号信息；
正确的设置 ulimit 和 kernel.core_pattern；
运行程序；
一旦你用 gdb 调试核心转储了，加载符号并运行 bt；
尝试找出发生了什么！
我可以使用 gdb 弄清楚有个 C++ 的虚表条目指向一些被破坏的内存，这有点帮助，并且使我感觉好像更懂了 C++ 一点。也许有一天我们会更多地讨论如何使用 gdb 来查找问题！
英文：Julia Evans
linux.cn/article-9834-1.html
程序员大咖整理发布，转载请联系作者获得授权
扫一扫
3471
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
