生成核心转储

Question

我的Go程序有时会崩溃。我尝试了一些操作，以便为此程序生成核心转储：在系统上定义ulimit，我尝试了两者ulimit -c unlimited，ulimit -c 10000以防万一。启动恐慌程序后，我没有任何核心转储。我还在recover()程序中添加了支持，并添加了代码以在出现紧急情况时登录到syslog，但在syslog中却什么也没得到。我现在想法不多了。我一定忽略了一些东西，但是我找不到，任何帮助将不胜感激。

Answer 1

请注意，当满足特定集合中的条件时，操作系统会生成核心转储。这些条件是非常低级的—例如，尝试访问未映射的内存或尝试执行CPU不知道的操作码等。在诸如Linux之类的POSIX操作系统下，当进程执行以下操作之一时，会向其中发送适当的信号：它和其中的一些（如果未由进程处理）具有生成核心转储的默认操作，如果未通过设置一定的限制来禁止，则由OS进行。

现在观察到，该机器将进程视为可能的最低级别（机器代码），但是Go编译器生成的二进制文件比C编译器（或汇编器）生成的二进制文件更高的级别，这意味着在生成的进程中某些错误Go编译器由Go运行时而不是OS处理。例如，在C编译器产生的进程中，典型的NULL指针取消引用通常导致向进程发送SIGSEGV信号，然后信号通常导致尝试转储进程的内核并终止它。相比之下，当这种情况发生在由 Go 编译器编译的进程中时，Go 运行时会启动并发生恐慌，从而产生用于调试目的的良好堆栈跟踪。

考虑到这些事实，我将尝试这样做：

1. 将程序包装在shell脚本中，该脚本首先放宽对核心转储的限制（但请参见下文），然后运行其标准错误流重定向到文件（或通过管道传输到logger二进制文件等）的程序。

2. 限制的用户可以调整有一个层次：有软，硬限制-看看这和这一个解释。因此，请尝试检查系统的核心转储大小没有设置为硬限制为0，因为这可以解释为什么您尝试提高此限制没有效果。

3. 至少在我的Debian系统上，当程序由于SIGSEGV而死时，该事实已由内核记录并在syslog日志文件中可见，因此请尝试对它们进行grep处理以获取提示。

Answer 2

1. 首先，请确保已处理所有错误。

2. 对于核心转储，您可以参考在Linux中生成核心转储。

3. 您可以使用超级用户在程序崩溃时重新启动程序。