面對錯誤，Mac OS開發時更好的保釋行爲

當我爲iPhone編寫程序時，蘋果環境在出現問題時會做什麼（從「無法識別的選擇器」到其他任何內容），應用程序崩潰並且控制檯，我有這樣的無意義的堆棧調試噴涌，看起來像這樣：面對錯誤，Mac OS開發時更好的保釋行爲

 
2009-12-19 11:57:37.843 ModelsProg[394:207] Stack: (
    30884955, 
    2431960329, 
    31266875, 
    30836342, 
    30688962, 
    10115, 
    2721311, 
    2759178, 
    2747272, 
    2729683, 
    2756789, 
    38981329, 
    30669696, 
    30665800, 
    2723433, 
    2760707, 
    9948, 
    9802 
)

老實說，我想不出一個更沒用方式，試圖幫助開發人員跟蹤bug。它甚至不告訴你問題來自哪裏，除非[394：207]是有關錯誤發生地點的一些神祕跡象。

如何我：

有MAC開發環境告訴我行號錯誤，文件發生
禁止無意義堆棧喋喋不休或將其更改爲__actual功能names__作爲輸出，如Python的崩潰的bug輸出看起來。

來源

2009-12-19 bobobobo

我已經開發了很多年的Mac軟件，我從來沒有見過，看起來這樣的事情堆棧跟蹤。你到底在做什麼？ – 2009-12-19 17:12:26

這是XCode中的iPhone開發，這是崩潰錯誤後控制檯的輸出。 – bobobobo 2009-12-19 17:29:54

是的，我收集到了。你需要回答的問題是「你在運行一個包含調試符號的可執行文件嗎？」和「在調試示例應用程序時，你會得到相同的輸出嗎？」 – 2009-12-19 17:45:21

您正在運行無符號的二進制文件（二進制版本，大概）或墜毀在一個地方，在crashtrace機制不能得到符號（比如未捕獲的異常）發生。這些＃是通常查找產生符號的地址。

一般情況下，對於這樣的堆棧溢出，在即將發生溢出之前的行上會有未捕獲的異常日誌消息。通常會給你幾乎所有你需要的信息。

但是，如果你做需要symbolicate堆棧跟蹤，有幾個方法可以做到這一點。

如果你在gdb，你可以使用info symbol 30884955（很明顯，用不同的數字代替）來獲得關於堆棧跟蹤中該地址符號的更多信息。 info line *30884955可能會產生更有用的結果。

但是，關鍵在於您需要符號文件可訪問的地方。從Xcode，他們應該只是在那裏（除非你已經打破了你的應用程序的符號生成配置）。否則，您需要使用symbol-file命令加載它們。

如果你想自動完成這個或做symbolication GDB之外，使用atos命令。

來源

2009-12-19 19:39:25 bbum

「碰撞跟蹤機制無法達到符號」 - 嗯！當我從XCode崩潰一個objective-c程序時，總會發生這種情況。您建議追蹤錯誤來源的方式看起來非常手動。什麼是「符號文件」？ – bobobobo 2009-12-19 19:47:50

符號文件是編譯器爲使可執行文件與源關聯而編寫的位。請參閱文檔。你還沒有指出什麼是例外;您在Debug下表明您有能力在異常提升中設置斷點。再次查看文檔（或谷歌）。 – bbum 2009-12-20 06:23:55

面對錯誤，Mac OS開發時更好的保釋行爲

回答

相關問題