来自Linux / gdb世界,默认处理程序清除进程之前,gdb默认在检测到SEGV时中断程序的执行。
lldb如何做类似的伎俩?目前该流程刚退出,无法查询回溯等。
修改:尝试了proccess handle -p true -n true -s true
- 没有结果:(
(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
修改:更多信息:
(lldb) bt all
error: invalid thread
我怀疑lldb
对于损坏的堆栈并不好玩 - 我正在尝试追踪涉及_NSExtensionMain
入口点的问题,或者从那里开始的问题。
答案 0 :(得分:3)
您应该根据this在lldb上输入process handle SIGSEGV --notify true --pass true --stop true
。
(lldb)进程句柄SIGSEGV --notify true --pass true --stop true
答案 1 :(得分:0)
我做了一个快速测试程序,
#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;
}
然后我尝试调试它,告诉lldb停在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)
好的,这看起来像我们的期望。我也可以让lldb直接转发信号而不停止:
(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)
看起来它就像我们想要的那样:lldb通知我们收到了信号,然后将其发送给程序。
这是在安装了Xcode 6的Mac OS X上。