总是收集libc回溯有什么优点和缺点？

Question

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

对于调试各种各样的错误，如内存，并发错误等，会不会很有帮助？我想这不会影响正常的表现，以及它只会在错误路径中触发。

Answer 1

由于该问题时，是非常有用总是收集基于软件的回溯

是的，这通常是非常有用的崩溃堆栈跟踪时：

• 您代码运行在你自己的环境中，并且你并不担心堆栈跟踪揭示任何秘密。
• 时死机处理程序不进一步破坏信息转储，不挂等

喜欢使用libc的回溯

的glibc在一定条件下backtrace调用calloc，而不是安全在碰撞处理程序中。它可能会导致死机和上述进一步的腐败。编写一个能够以异步信号安全的方式可靠地打印堆栈跟踪的崩溃处理程序是相当不重要的。

为什么然后在“标准”应用程序中执行错误函数而不回调函数？

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

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

这是所有你真正需要知道的。做这个打印什么都没用。如果你有很多这样的文件，并且cat为每个文件打印完整的堆栈跟踪信息，那么你会得到很多错误输出页面，这只会让你更难找到真正的问题。

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

但是，如果他们没有赶上信号，呼吁backtrace，backtrace_symbols，或backtrace_symbols_fd从信号处理程序也同样不安全的，并可能死锁，这比简单地倾倒核心更糟。考虑一下如果你有一个长时间运行的脚本，并且里面有1000个命令，会发生什么。你启动它，一个星期后发现它没有任何进展，因为第二个命令崩溃并试图打印崩溃堆栈跟踪时死锁。