总是收集libc回溯的利弊是什么？

Question

正如问题所述，始终在所有错误函数和信号处理程序中收集基于软件的回溯（如使用libc backtrace http://www.gnu.org/software/libc/manual/html_node/Backtraces.html）是否有用？

调试各种错误（如内存，并发错误等）不是很有用吗？我想这不会影响正常的性能，只会在错误路径中触发。

Answer 1

  

正如问题所述，始终收集基于软件的回溯是否有用

是的，在以下情况下拥有崩溃堆栈跟踪通常非常有用：

• 您的代码在您自己的环境中运行，您并不担心堆栈跟踪泄露任何秘密。
• 当崩溃处理程序没有进一步破坏coredump时，不会挂起等等。

  

喜欢使用libc backtrace

glibc backtrace在某些条件下调用calloc，并且在崩溃处理程序中不安全。它可能导致挂起和上面提到的进一步损坏。编写一个可以以异步信号安全的方式可靠地打印堆栈跟踪的崩溃处理程序是非常重要的。

  

为什么“标准”应用程序中的错误函数不会调用回溯？

考虑cat /no/such/file。目前它产生：

cat: /no/such/file: No such file or directory

这是所有你真正需要知道的。将这种印刷品变成其他东西是没用的。如果你有很多这样的文件，并且cat为每个文件打印了一个完整的堆栈跟踪，你会得到很多页面的错误输出，这只会让你更难找到真正的问题。

对于致命信号处理程序（例如SIGSEGV），答案是大多数“标准”应用程序实际上并不处理此类信号，只是使用默认操作，这会产生核心转储。

但是如果他们确实捕获了信号，那么从信号处理程序调用{​​{1}}，backtrace或backtrace_symbols同样不安全，并且可能会死锁，这比简单地倾倒更糟糕核心。考虑如果你有一个包含1000个命令的长时间运行脚本会发生什么。你启动它，一周后发现它没有取得任何进展，因为第二个命令崩溃并且死锁，试图打印崩溃堆栈跟踪。