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

Question

我的 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

标签： debugginggo

Answer 1

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

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

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

因此，首先要做的是实际阅读并理解所显示的错误。它包含导致 Go 运行时导致程序崩溃的直接原因——它可能是nil指针取消引用、内存耗尽、试图关闭关闭的通道等等。

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

但是这样的错误很少见，而且高级错误发生的频率要高得多。与他们一起，检查堆栈跟踪有很大帮助。

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

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

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

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

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

但是，我们现在不要深入挖掘。这里还有其他要探索的东西（比如，我已经谈到了内存耗尽错误，但没有解释如何处理它们），但你最好还是通过实践来学习自己的方式。

如果您在处理此类问题时有任何具体问题，请尽管提出，但请确保包含崩溃的 goroutine 的堆栈跟踪，并描述您自己的分析尝试产生了什么，以及您到底遇到了什么问题。

---

您可以使用另一种方法。

可以为环境变量分配一个特殊值，以告诉 Go 运行时以一种对能够处理核心转储GOTRACEBACK的“常规”交互式调试器友好的方式使您的程序崩溃——例如.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调试器。

跑help ulimit进去bash看看ulimit上面的咒语是关于什么的。）