How to tell LLDB to pass signal onto program

Question

I set a lot of breakpoints in lldb for a C language based application I installed on my MacOS. The breakpoints were mostly set in the same function in the application. However, the next day that I went back to the application to continue working on it, and I started setting breakpoints again in the same function, a problem arose in that the break didn't occur inside the application function, but rather in one of the underlying libraries of the application and it keeps doing this over and over again everytime I try to break in the function (i.e. it's stopping in the underlying library) and I'm not able to reach the desired function by stepping (every time I step, it just steps forward in the underlying library).

Update:

The function I am setting the breakpoint in is called from within a signal handler. For example when I send a SIGINT signal, the signal handler calls some functions to cleanup in the application, and I am setting the breakpoint on one of those functions that cleanup. Sometimes, LLDB stops in the function that I set the breakpoint in (with stop reason = breakpoint 1.1) , sometimes it stops in the underlying/included event handling library with stop reason = signal SIGSTOP and, if the latter, if I press "c" (to continue onto the breakpoint in the application hopefully and out of the event handling library), only sometimes does it let me continue onto the desired breakpoint, othertimes it just says "Process 41524 resuming" and I can never get to the desired breakpoint.

Answer 1

Ah, then I don't think the problem was with breakpoints, but with whether your signal handler was actually getting called.

Most debuggers have some way to control what happens when a signal is received. In lldb this is done through the process handle command. For instance:

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

That means lldb will stop when your process is given a SIGSTOP, and will notify you about the SIGSTOP, but will NOT pass the SIGSTOP on to the program you are debugging (and thus your handler will not get called for SIGSTOP.) process handle with no arguments will give you the list of behaviors for all signals.

We don't pass SIGSTOP by default because it is used by the debugger for its own purposes, and so you might get calls to your handler that didn't come from "real" SIGSTOP's. The same is true, for the same reason, of SIGINT:

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

You can easily change this behavior, for instance for SIGINT:

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

Then the debugger will pass the SIGINT on to the process, and it will stop in your handler.