總是收集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個命令，會發生什麼。你啓動它，一個星期後發現它沒有任何進展，因爲第二個命令崩潰並試圖打印崩潰堆棧跟蹤時死鎖。