2017-03-01 43 views
0

我在lldb中爲我安裝在MacOS上的基於C語言的應用程序設置了很多斷點。斷點大多在應用程序中設置爲相同的功能。然而,第二天我回到應用程序繼續工作,並且我開始在同一個函數中再次設置斷點,出現了一個問題,即應用程序函數內部沒有發生中斷,而是出現在該應用程序的底層庫,並且每當我嘗試打破該函數時(例如停止在底層庫中),它都會一遍又一遍地執行此操作,並且我無法通過步進來達到所需的功能(每次我步,它只是在底層庫中向前邁進)。如何告訴LLDB將信號傳遞到程序

更新:

我設置的是從信號處理程序中調用斷點功能。例如,當我發送一個SIGINT信號時,信號處理程序會調用一些函數來在應用程序中進行清理,並且我正在設置其中一個清理函數的斷點。有時候,LLDB會停止在我設置斷點的函數中(使用stop reason = breakpoint 1.1),有時它會停止在底層/包含的事件處理庫中,並且如果後者是按下「c」(繼續進入斷點該應用程序希望並且不在事件處理庫中),但有時它可以讓我繼續到期望的斷點,其他時候它只是說「過程41524恢復」,並且我永遠不能達到期望的斷點。

+0

您是否使用Xcode設置斷點或命令行lldb?如果Xcode,它會緩存斷點,但可以在斷點瀏覽器中禁用它們。 –

+0

如果這是命令行lldb,它不會緩存從運行到運行lldb本身,儘管它會保持您設置爲活動的斷點並在每次重新運行正在調試的程序時重置它們。 –

+0

如果你可以給出「break list」命令的輸出和你意想不到的斷點數,也許我們可以看到有趣的東西? –

回答

2

啊,那麼我認爲問題不在於斷點,而在於你的信號處理程序是否真的被調用。

大多數調試器都有一些方法來控制接收信號時發生的情況。在lldb中,這是通過process handle命令完成的。例如:

(lldb) process handle SIGSTOP 
NAME   PASS STOP NOTIFY 
=========== ===== ===== ====== 
SIGSTOP  false true true 

這意味着,當你的進程給出一個SIGSTOP LLDB將停止,並且會通知您的SIGSTOP,但不會傳遞給程序正在調試的SIGSTOP(因此您的處理程序將沒有被調用SIGSTOP。)沒有參數的process handle會給你所有信號的行爲列表。

我們不會默認傳遞SIGSTOP,因爲它被調試器用於自己的目的,所以您可能會調用不是來自「真正的」SIGSTOP的處理程序。同樣如此,出於同樣的原因,SIGINT的:

(lldb) process handle SIGINT 
NAME   PASS STOP NOTIFY 
=========== ===== ===== ====== 
SIGINT  false true true 

您可以輕鬆地改變這種行爲,例如用於信號情報:

(lldb) process handle SIGINT -p true 
NAME   PASS STOP NOTIFY 
=========== ===== ===== ====== 
SIGINT  true true true 

然後調試器會傳遞給進程SIGINT ,它會停在你的處理程序中。

+1

好的,謝謝。我認爲沒有任何改變(即它不能在開始一個過程之前配置),因爲你在2013年回答這個問題http://stackoverflow.com/questions/16989988/disable-signals-at-lldb-initialization我跑了'幫助過程處理「,但沒有找到更多信息 – Leahcim

+0

是的,這還沒有得到修復。 –

0

由於故障排除指南中提到,增加了target.inline-breakpoint-strategy設置到.lldbinit文件似乎解決問題

"settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit 

更新:問題不是固定不變的,看到OP,所以這不是一個很好的解決方案(據我所知)

+0

將此行添加到'.lldbinit'中,但稍後它恢復爲OP – Leahcim

+0

中描述的行爲。「停在不存在的斷點處」是什麼意思?當你停下來時,lldb的停止原因是「斷點x.x」還是EXC_BREAKPOINT?如果是後者,那麼這不是一個斷點lldb集合,但它是某個系統庫在斷言中使用相同的陷阱。爲EXC_BREAKPOINT搜索StackOverflow以瞭解這種情況的大量示例。 –

+0

我用更詳細的信息更新了OP。 – Leahcim

相關問題