我的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代码中，紧急情况/恢复机制不用于控制流，因此，当出现某些goroutine紧急情况时，通常会有一个相当严重的理由。反过来，这意味着，这种原因通常仅限于一组不太广泛的可能原因，并且在100％的这种情况下，它表示程序中的逻辑错误:尝试取消引用统一的(nil)指针，即尝试发送到封闭频道等。
(当然，问题可能出在第三方代码或您使用它的方式上。)
好的，因此要开始分析发生了什么，首先要停止将其视为“发生了某些错误”:相反，发生了一些特定的错误，并且Go运行时向您显示了当时所有goroutine的状态。时间。
因此，要做的第一件事是实际阅读并理解所显示的错误。它包含导致Go运行时导致程序崩溃的直接原因-可能是nil指针取消引用，内存耗尽，试图关闭已关闭的通道等。
第二件事-一旦清楚地理解了错误的本质-是分析堆栈跟踪转储是否有用。很简单:所有运行时错误都可以分为两大类:“低级”或“高级”。前者是那些发生在Go运行时本身中的事件。分配内存失败是最好的例子。此类错误甚至可能表明运行时存在错误(尽管在实践中很难看到这种错误，除非您使用Go工具集的最新版本来构建程序)。此类错误的主要特征是，它们可能与错误发生的确切位置无关。说，分配内存失败可能是由一些无辜的分配触发的，而一些实际的内存占用泄漏内存成功地设法在之前获得了大块内存。
但是这种错误很少见，高级错误的发生频率越来越高。借助它们，检查堆栈跟踪很有帮助。
在这些情况下，您会像这样滚动。
堆栈跟踪转储包括导致错误的调用链堆栈框架的描述:发生错误的函数的堆栈框架在顶部，其调用方在下方，调用方的调用方在下一个一直到执行goroutine的入口点。
每个堆栈框架的描述都包括函数的名称和在其中定义函数的文件的名称，以及在其中发生错误的语句的行号。
这本身非常有用:您可以在程序的源代码中找到该语句，斜视它，同时牢记指示的错误在那里发生，然后开始“向后”分析它可能如何发生，以至于它在那里。如果该语句之前的函数代码不清楚，则可能有助于分析调用方的堆栈框架(其中还包括文件名和行号)等等。
在大多数情况下，上述条件就足够了。
在极少数情况下，分析功能的参数(也会被其转储的堆栈框架捕获)可能会有所帮助。
参数的值按其源代码顺序列出-从左到右；解释它们的唯一问题是“解码”“复合”类型的参数，例如字符串，片段，使用过的struct类型等。
假设字符串是两个字段的struct，并且在参数列表中这些字段将一个接一个地“解开”。
但是，让我们暂时不深入研究。这里还有其他事情可以探索(例如，我已经谈到了内存耗尽错误，但没有说明如何解决)，但最好还是通过实践来尝试学习。
如果在处理此类问题时有任何具体问题，请–提出，但请确保包括崩溃的goroutine的堆栈跟踪，并描述您自己的分析尝试产生了什么，以及您究竟遇到了什么问题。
您可以使用另一种方法。
可以为 GOTRACEBACK 环境变量分配一个特殊值，以告知Go运行时以一种对能够使用core dumps的“常规”交互式调试器(例如gdb)友好的方式崩溃程序。
例如，您可以启用转储核心文件，然后允许Go运行时以某种方式使您的进程崩溃，以使OS转储其核心:
$ 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实例是关于什么的。)
关于debugging - 进入程序运行时错误并打印出所有内容，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57241766/