lldb break upon SIGSEGV

Question

Coming from the Linux/gdb world, the gdb by default interrupts the execution of the program upon detecting a SEGV, before the default handler cleans the process up.

How can lldb do the similar trick? Currently the process just exits, making it impossible to query the backtrace etc.

Edit: proccess handle -p true -n true -s true attempted - with no result :(

(lldb) process handle -p true -n true -s true SIGSEGV
NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGSEGV     true   true   true 
(lldb) run
Process 97630 launched: '/Volumes/My Finder Extensions 1/My_Daemon.app/Contents/PlugIns/My_ShellExt.appex/Contents/MacOS/My_ShellExt' (x86_64)
Process 97630 exited with status = 0 (0x00000000) Terminated due to signal 9

Edit: more information:

(lldb) bt all
error: invalid thread

I suspect lldb does not play nice with corrupted stacks - I'm trying to track down a problem involving a _NSExtensionMain entry point, or something down the line from there.

Are you sure your program is getting a SIGSEGV? Signal 9 is SIGKILL, and that can't be caught by a debugger (unless, possibly, there's some Mach-specific way to do it). — Mark Plotnick, Oct 23 '14 at 17:02
Something weird is going on here. We got an exit status (0) for the process, so it actually exited normally. Not sure why we also think it got a signal 9. BTW, if you are debugging a program and it gets a SIGKILL, it will stop in the debugger with the SIGKILL. The debugger can catch SIGKILL's, what it can't do is suppress them. — Jim Ingham, Oct 23 '14 at 19:52
Is it possible for you to try a step-by-step debugging ? I think your program overwrite a part of 'sensitive data' like IVT or PCB, that's may be why you can't do `backtrace`. — VivienG, Oct 24 '14 at 06:56
Actually, it seems that the problem arose from somewhat confusing stack situation (the bug is very early on in the Mach-O entry point), and yes, it is a function preamble causing memory access violation - before even application's default handlers are installed. Hence - Exit 0. — qdot, Oct 24 '14 at 14:05

score 5 · Answer 1 · edited May 23 '17 at 11:58

5

you should type process handle SIGSEGV --notify true --pass true --stop true on lldb according to this.

(lldb)process handle SIGSEGV --notify true --pass true --stop true

edited May 23 '17 at 11:58

Community

1
1

answered Oct 23 '14 at 13:52

VivienG

2,143
3
24
43

That sounds reasonable - but actually doesn't work in my case, no idea why. – qdot Oct 23 '14 at 14:32
1

Do you run your application on a remote target ? I had similar isue when I debuged a C application through JTAG to a remote target. I had to use OpenOCD to final got what I need. But I don't think this is your case, right ? – VivienG Oct 23 '14 at 15:12
Local target, somewhat strange application entry point (attempting to write an application extension mostly in C++ to reuse Linux/Win32 code) – qdot Oct 23 '14 at 15:18
When your app die can you type `bt all` and put the result as an edit to your main post please. – VivienG Oct 23 '14 at 15:22

score 0 · Answer 2 · answered Oct 23 '14 at 18:11

I made a quick test program,

#include <signal.h>
#include <stdio.h>
#include <unistd.h>

void handler (int in)
{
    puts ("signal received");
}

int main ()
{
    signal (SIGSEGV, handler);    
    kill (getpid (), SIGSEGV);
    return 0;
}

Then I try debugging it where I tell lldb to stop on SIGSEGV:

(lldb) br s -n main
(lldb) r
(lldb) pr h -p true -n true -s true SIGSEGV
NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGSEGV     true   true   true 
(lldb) c
Process 5024 resuming
Process 5024 stopped

(lldb) bt
* thread #1: tid = 0x19d6ae, 0x00007fff8f27fc7e libsystem_kernel.dylib`__kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
  * #0: 0x00007fff8f27fc7e libsystem_kernel.dylib`__kill + 10
    #1: 0x0000000100000f25 a.out`main + 53 at a.c:13
    #2: 0x00007fff8c0e65c9 libdyld.dylib`start + 1
(lldb) c
Process 5024 resuming
signal received
Process 5024 exited with status = 0 (0x00000000) 
(lldb)

OK so that looks like what we expected. I can also ask lldb to just forward the signal on without stopping:

(lldb) br s -n main
(lldb) r
(lldb) pr h -p true -n true -s false SIGSEGV
NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGSEGV     true   false  true 
(lldb) c
Process 5055 resuming
Process 5055 stopped and restarted: thread 1 received signal: SIGSEGV
signal received
Process 5055 exited with status = 0 (0x00000000) 
(lldb)

and that looks like it did what we wanted: lldb notified us that the signal was received and then sent it to the program.

This is on Mac OS X with Xcode 6 installed.

lldb break upon SIGSEGV

2 Answers2