Go程序运行时错误并打印出所有内容

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《Go程序运行时错误并打印出所有内容》，文章讲解的知识点主要包括，如果你对Golang方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

我的 go 代码使用了数百个 goroutine。有时可能会发生运行时错误。但是当错误发生时，它只会打印出所有 goroutine 的堆栈跟踪，从而导致无法调试？

如何定位程序中断的位置？

对不起，我之前没有发布堆栈跟踪，我不知道如何打印 stderr 到堆栈，而且输出太长，所以我无法查看全部内容。

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x141edce pc=0x141edce]

runtime stack:
runtime: unexpected return pc for runtime.sigpanic called from 0x141edce
stack: frame={sp:0x7ffbffffa9f0, fp:0x7ffbffffaa40} stack=[0x7ffbff7fbb80,0x7ffbffffabb0)
00007ffbffffa8f0:  00007ffbffffa960  000000000042b58c <runtime.dopanic_m+540> 
00007ffbffffa900:  000000000042b031 <runtime.throw+129>  00007ffbffffa9d0 
00007ffbffffa910:  0000000000000000  000000000097f880 
00007ffbffffa920:  010000000042bae8  0000000000000004 
00007ffbffffa930:  000000000000001f  000000000141edce 
00007ffbffffa940:  000000000141edce  0000000000000001 
00007ffbffffa950:  00000000007996e6  000000c420302180 
00007ffbffffa960:  00007ffbffffa988  00000000004530ac <runtime.dopanic.func1+60> 
00007ffbffffa970:  000000000097f880  000000000042b031 <runtime.throw+129> 
00007ffbffffa980:  00007ffbffffa9d0  00007ffbffffa9c0 
00007ffbffffa990:  000000000042af5a <runtime.dopanic+74>  00007ffbffffa9a0 
00007ffbffffa9a0:  0000000000453070 <runtime.dopanic.func1+0>  000000000097f880 
00007ffbffffa9b0:  000000000042b031 <runtime.throw+129>  00007ffbffffa9d0 
00007ffbffffa9c0:  00007ffbffffa9e0  000000000042b031 <runtime.throw+129> 
00007ffbffffa9d0:  0000000000000000  000000000000002a 
00007ffbffffa9e0:  00007ffbffffaa30  000000000043fb1e <runtime.sigpanic+654> 
00007ffbffffa9f0: <000000000079dce7  000000000000002a 
00007ffbffffaa00:  00007ffbffffaa30  000000000041f08e <runtime.greyobject+302> 
00007ffbffffaa10:  000000c420029c70  000000000097f880 
00007ffbffffaa20:  000000000045247d <runtime.markroot.func1+109>  000000c420a69b00 
00007ffbffffaa30:  00007ffbffffaad8 !000000000141edce 
00007ffbffffaa40: >000000c42160ca40  000000c4206d8000 
00007ffbffffaa50:  0000000000000c00  000000c41ff4f9ad 
00007ffbffffaa60:  000000c400000000  00007efbff5188f8 
00007ffbffffaa70:  000000c420029c70  0000000000000052 
00007ffbffffaa80:  0000000021e84000  00007ffbffffaab0 
00007ffbffffaa90:  0000000000002000  0000000000000c00 
00007ffbffffaaa0:  000000c422b00000  000000c420000000 
00007ffbffffaab0:  00007ffbffffaad8  0000000000421564 <runtime.(*gcWork).tryGet+164> 
00007ffbffffaac0:  000000c41ffc939f  000000c4226eb000 
00007ffbffffaad0:  000000c4226e9000  00007ffbffffab30 
00007ffbffffaae0:  000000000041e527 <runtime.gcDrain+567>  000000c4206d8000 
00007ffbffffaaf0:  000000c420029c70  0000000000000000 
00007ffbffffab00:  7ffffffffff8df47  00007ffc0001fc30 
00007ffbffffab10:  00007ffbffffab70  0000000000000000 
00007ffbffffab20:  000000c420302180  0000000000000000 
00007ffbffffab30:  00007ffbffffab70  00000000004522c0 <runtime.gcBgMarkWorker.func2+128> 
runtime.throw(0x79dce7, 0x2a)
    /usr/lib/go-1.10/src/runtime/panic.go:616 +0x81
runtime: unexpected return pc for runtime.sigpanic called from 0x141edce
stack: frame={sp:0x7ffbffffa9f0, fp:0x7ffbffffaa40} stack=[0x7ffbff7fbb80,0x7ffbffffabb0)
00007ffbffffa8f0:  00007ffbffffa960  000000000042b58c <runtime.dopanic_m+540> 
00007ffbffffa900:  000000000042b031 <runtime.throw+129>  00007ffbffffa9d0 
00007ffbffffa910:  0000000000000000  000000000097f880 
00007ffbffffa920:  010000000042bae8  0000000000000004 
00007ffbffffa930:  000000000000001f  000000000141edce 
00007ffbffffa940:  000000000141edce  0000000000000001 
00007ffbffffa950:  00000000007996e6  000000c420302180 
00007ffbffffa960:  00007ffbffffa988  00000000004530ac <runtime.dopanic.func1+60> 
00007ffbffffa970:  000000000097f880  000000000042b031 <runtime.throw+129> 
00007ffbffffa980:  00007ffbffffa9d0  00007ffbffffa9c0 
00007ffbffffa990:  000000000042af5a <runtime.dopanic+74>  00007ffbffffa9a0 
00007ffbffffa9a0:  0000000000453070 <runtime.dopanic.func1+0>  000000000097f880 
00007ffbffffa9b0:  000000000042b031 <runtime.throw+129>  00007ffbffffa9d0 
00007ffbffffa9c0:  00007ffbffffa9e0  000000000042b031 <runtime.throw+129> 
00007ffbffffa9d0:  0000000000000000  000000000000002a 
00007ffbffffa9e0:  00007ffbffffaa30  000000000043fb1e <runtime.sigpanic+654> 
00007ffbffffa9f0: <000000000079dce7  000000000000002a 
00007ffbffffaa00:  00007ffbffffaa30  000000000041f08e <runtime.greyobject+302> 
00007ffbffffaa10:  000000c420029c70  000000000097f880 
00007ffbffffaa20:  000000000045247d <runtime.markroot.func1+109>  000000c420a69b00 
00007ffbffffaa30:  00007ffbffffaad8 !000000000141edce 
00007ffbffffaa40: >000000c42160ca40  000000c4206d8000 
00007ffbffffaa50:  0000000000000c00  000000c41ff4f9ad 
00007ffbffffaa60:  000000c400000000  00007efbff5188f8 
00007ffbffffaa70:  000000c420029c70  0000000000000052 
00007ffbffffaa80:  0000000021e84000  00007ffbffffaab0 
00007ffbffffaa90:  0000000000002000  0000000000000c00 
00007ffbffffaaa0:  000000c422b00000  000000c420000000 
00007ffbffffaab0:  00007ffbffffaad8  0000000000421564 <runtime.(*gcWork).tryGet+164> 
00007ffbffffaac0:  000000c41ffc939f  000000c4226eb000 
00007ffbffffaad0:  000000c4226e9000  00007ffbffffab30 
00007ffbffffaae0:  000000000041e527 <runtime.gcDrain+567>  000000c4206d8000 
00007ffbffffaaf0:  000000c420029c70  0000000000000000 
00007ffbffffab00:  7ffffffffff8df47  00007ffc0001fc30 
00007ffbffffab10:  00007ffbffffab70  0000000000000000 
00007ffbffffab20:  000000c420302180  0000000000000000 
00007ffbffffab30:  00007ffbffffab70  00000000004522c0 <runtime.gcBgMarkWorker.func2+128> 
runtime.sigpanic()
    /usr/lib/go-1.10/src/runtime/signal_unix.go:372 +0x28e

解决方案

实际上，通过转储这些堆栈可以轻松进行调试。 您可能不熟悉这种事后分析方法，但这可以修复;-)

首先要注意的是，在正常的 go 代码中，panic/recover 机制不用于控制流，因此当某些 goroutine 发生恐慌时，它通常有一个非常严重的理由这样做。反过来，这意味着，此类原因通常仅限于不太广泛的可能原因，并且在 100% 的此类情况下，它表示程序中存在逻辑错误：尝试取消引用未初始化的对象。 (nil) 指针、尝试发送到关闭的通道等。 （当然，问题可能出在第 3 方代码上，或者出在您使用它的方式上。）

好的，所以要开始分析发生了什么，首先不要将其视为“发生了错误”：相反，发生了一些特定错误，并且 go 运行时向您显示那一刻所有 goroutine 的状态。

因此，要做的第一件事就是实际阅读并理解所显示的错误。它包含导致 go 运行时崩溃程序的直接原因 - 可能是 nil 指针取消引用、内存耗尽、尝试关闭已关闭的通道等等。

第二件事要做——一旦清楚地理解了错误的本质——就是分析堆栈跟踪转储是否有用。很简单：所有运行时错误都可以分为两大类：“低级”或“高级”。前者发生在 go 运行时本身的深处。分配内存失败就是最好的例子。此类错误甚至可能表明运行时中存在错误（尽管这在实践中不太可能看到，除非您使用 go 工具集的前沿构建来构建程序）。此类错误的主要特性是它们可能与错误发生的确切位置无关。比如说，分配内存的失败可能是由一些无辜的分配触发的，而一些真正的内存占用者泄漏内存之前成功地获得了一大块内存。

但此类错误很少见，而且高级错误发生的频率要高得多。有了它们，检查堆栈跟踪会有很大帮助。

在这些情况下，你会像这样滚动。 堆栈跟踪转储由导致错误的调用链的堆栈帧的描述组成：发生错误的函数的堆栈帧位于顶部，其调用者位于下面，调用者的调用者是下一个，依此类推——直到执行 goroutine 的入口点。 每个堆栈帧的描述包括函数的名称和定义该函数的文件的名称以及发生错误的语句的行号。

这本身就非常有用：您可以在程序的源代码中找到该语句，眯着眼睛看它，同时记住指示的错误发生在那里，然后开始“向后”分析它怎么会发生在那个地方。如果该语句之前的函数代码不清楚，分析调用者的堆栈帧（其中还包括文件名和行号）等可能会有所帮助。

在大多数情况下，上述内容就足够了。 在极少数情况下，如果没有，分析函数的参数（也通过转储的堆栈帧捕获）可能会有所帮助。

参数的值按照源代码顺序列出——从左到右；解释它们的唯一问题是“解码”那些“复合”类型的参数 - 例如字符串、切片、使用定义的 struct 类型等。

比如说，一个字符串是一个包含两个字段的 struct，并且在参数列表中，这些字段将一个接一个地出现，“展开”。

但我们现在不要挖得太深。这里还有其他事情需要探索（例如，我已经谈到了内存耗尽错误，但没有解释如何处理它们），但你最好通过实践来真正尝试学习你的方法。

如果您在处理此类问题时有任何具体问题，请不要问，但一定要包括崩溃的 goroutine 的堆栈跟踪，并描述您自己的分析尝试产生了什么结果，以及什么结果正是您遇到的问题。

还有另一种方法可供您使用。

可以为 GOTRACEBACK 环境变量分配一个特殊值，以告诉 go 运行时以一种对能够使用 core dumps 的“常规”交互式调试器友好的方式崩溃您的程序 - 例如 gdb。

例如，您可以启用核心文件转储，然后允许 go 运行时以某种方式崩溃您的进程，以便操作系统转储其核心：

$ ulimit -c unlimited
$ export GOTRACEBACK=crash
$ ./your_program
...
... your_program crashes
...
$ ls *core*
core
$ gdb -e ./your_program core
(gdb) thread apply all bt
   * tracebacks follow *

（我想，核心文件捕获的状态的实际调试是您的 ide 或其他任何应该处理的事情；我演示了如何运行 gdb 调试器。

在 bash 中运行 help ulimit 来查看上面的 ulimit 咒语是关于什么的。）

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Go程序运行时错误并打印出所有内容》文章吧，也可关注golang学习网公众号了解相关技术文章。