lldb調試器可以使用python腳本實現功能增強，但也不是可以隨心所欲的，在實際中有很多地方需要注意。

首先是對多線程環境調試使用python腳本，也要考慮python腳本有多線程安全，尤其是有許多任務繁重的工作線程，目標函數許多線程同時在使用時，腳本用到的全局變量就成了臨界資源。如果只是通常地是使用python實現增強調試指令，手工指令顯示結果，調試器運行在交互狀態，就不會想到使用python腳本也會多線程運行。但是在做斷點catch調試時，腳本自動在各catch點觸發的線程上運行，沒錯python腳本運行在多線程環境了。python腳本用鎖后，就要注意一個問題，鎖住的代碼塊要考慮腳本異常后，因為鎖沒有釋放使其它線程在catch點上餓死，影響了程序的運行，當然設計的調試自然就失敗（不工作，達不到目的）了。

第二，也是與catch調試情況相關的，就是要注意調試時調用了程序的函數與catch點之間是否存在依賴關系。如果存在依賴關系，catch點觸發的函數調用又使用了catch點的代碼，結果就是catch點遞歸觸發，或者說這里鏈環。通常調試器會在這種情況輸出警告提示，"warning:hit point ..., skip the command..."，就是調試器嘗試跳過catch點定下的操作，但是并不是總能有效。最后結果只有一個，主線程被異常事件喚醒停在mach_msg_trap，也就是程序掛了。lldb比gdb在p指令多了一個打印對象的功能，這個功能并非由調試器實現的，而是調用了oc對象的description函數，和NSLog打印oc對象一樣，調用了被打印的oc對象的函數。如果想在catch點，通過以上兩種方法獲取oc對象的打印信息，這就要考慮以上兩種方法所依賴的函數或機制流程了。舉例，在_pthread*的函數集合，catch觸發操作打印一個oc字符串（po @"abc" 或 p (void)NSLog(@"abc")），調試繼續，悲劇隨即發生，程序掛了。因為觸發的catch操作依賴了_pthread*的函數。跟著了catch觸發操作引起的流程循環，如果你想在CFRunLoop里面的各步驟中，使用以上兩種打印對象信息的方法，就要當心會不會引起了某個CFRunLoop的事件，又使得CFRunLoop因此又運行在你的catch點上。我嘗試在RunLoop的observer點的回調函數catch打印info的信息，結果程序運行就掛了。沒錯，你發現了，本篇寫的就是我踩過的坑。

第三，就是不要在python腳本中，通過HandleCommand執行調試器指令來讀取寄存器，不要指望能正確讀出中斷現場的寄存器的值。因為python腳本運行在lldb之上，現在又由python調用lldb的命令（或指令），所以在這樣的情景下，lldb讀寄存器命令與程序中斷（或斷點）現場就相隔著一層python，lldb調試命令很自然就不是在讀取程序斷點的現場。因此在python腳本就必須使用lldb.frame.register來讀取讀取程序斷點的現場，因為這是python的lldb模塊對lldb調試器保存的寄存器現場進行了keep one copy。

?

轉載于:https://www.cnblogs.com/bbqzsl/p/5530695.html

總結

以上是生活随笔為你收集整理的lldb调试使用python脚本问题总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。