前面说到，在bionic/linker客户端以及system/core/dubuggerd服务端之间都加了相关的SIGSYS信号量处理，但还是抓不出tombstone，现查看原因。
先说结论:由于设置了信号处理函数导致的问题
简单demo类比场景
首先本地写个demo来尝试复现类似场景
tips: new project时勾选include C++ support，非常适合用于需要调用jni的简单demo
package com.test.weijuncheng.myapplication;
import android.content.ComponentName;
import android.content.Context;
import android.content.Intent;
import android.content.ServiceConnection;
import android.os.IBinder;
import android.os.RemoteException;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;
import com.test.weijuncheng.myapplication.services.IIsolatedService;
import com.test.weijuncheng.myapplication.services.IsolatedService;
class IsolatedServiceConnection implements ServiceConnection {
private IIsolatedService isolatedService;
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
isolatedService = IIsolatedService.Stub.asInterface(service); //通过onBind返回的binder对象，通过asInterface接口得到其代理
try {
isolatedService.CreatewillCrash();
} catch (RemoteException e) {
e.printStackTrace();
}
}
@Override
public void onServiceDisconnected(ComponentName name) {
}
}
public class MainActivity extends AppCompatActivity {
// Used to load the 'native-lib' library on application startup.
static {
System.loadLibrary("native-lib");
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// Example of a call to a native method
TextView tv = (TextView) findViewById(R.id.sample_text);
tv.setText(stringFromJNI());
Button btn1 = (Button)findViewById(R.id.button1);
btn1.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Log.i("weijuncheng","btn0");
//SignalHandlerInit1();
//CreateWillCrash1();
//CreateSignalSIABRT();
bindService(new Intent(MainActivity.this,IsolatedService.class),new IsolatedServiceConnection(), Context.BIND_AUTO_CREATE);
}
});
//SignalHandlerInit1();
//CreateWillCrash1();
//bindService(new Intent(MainActivity.this,IsolatedService.class),new IsolatedServiceConnection(), Context.BIND_AUTO_CREATE);
}
/**
* A native method that is implemented by the 'native-lib' native library,
* which is packaged with this application.
*/
public native String stringFromJNI();
public native void CreateWillCrash1();
public native void SignalHandlerInit1();
public native void CreateSignalSIABRT();
}
package com.test.weijuncheng.myapplication.services;
import android.app.Service;
import android.content.ComponentName;
import android.content.Intent;
import android.content.ServiceConnection;
import android.os.IBinder;
import android.os.RemoteException;
import android.support.annotation.Nullable;
import android.util.Log;
public class IsolatedService extends Service{
static {
System.loadLibrary("native-lib");
}
public native void ServiceCreateWillCrash1();
public native void ServiceCreateWillCrash2();
public native void SignalHandlerInit();
//Alt+Insert需要实现的方法
@Nullable
@Override
public IBinder onBind(Intent intent) {
return mService; //返回binder实例
//不管怎样都要返回一个实例，无论是自建还是通过AIDL
}
//Stub继承自binder,Stub实例就是binder实例
private final IIsolatedService.Stub mService = new IIsolatedService.Stub(){
@Override
public void CreatewillCrash() throws RemoteException {
//CreateWillCrash();
System.out.println("CreatewillCrash ");
Log.i("weijuncheng1","CreatewillCrash");
SignalHandlerInit();
//ServiceCreateWillCrash1();
ServiceCreateWillCrash2();
}
};
}
#include
#include
#include
#include
#include
#include
#include
#include
extern "C" JNIEXPORT jstring JNICALL
Java_com_test_weijuncheng_myapplication_MainActivity_stringFromJNI(
JNIEnv *env,
jobject /* this */) {
std::string hello = "Hello from C++";
return env->NewStringUTF(hello.c_str());
}
extern "C"
JNIEXPORT void JNICALL
Java_com_test_weijuncheng_myapplication_MainActivity_CreateWillCrash1(JNIEnv *env,
jobject instance) {
// TODO
std::string test = NULL; //相当于调用abort函数，本身自带发送两次，所以必闪退
}
extern "C"
JNIEXPORT void JNICALL
Java_com_test_weijuncheng_myapplication_services_IsolatedService_ServiceCreateWillCrash2(JNIEnv *env,
jobject instance) {
// TODO
std::string test1 = NULL;
}
void signal_handler(int signal_number, siginfo* info, void *){
std::cout<<"weijuncheng handle SIGABRT signal"<si_code >= 0 || info->si_code == SI_TKILL) {
// rt_tgsigqueueinfo(2)'s documentation appears to be incorrect on kernels
// that contain commit 66dd34a (3.9+). The manpage claims to only allow
// negative si_code values that are not SI_TKILL, but 66dd34a changed the
// check to allow all si_code values in calls coming from inside the house.
}
__android_log_print(ANDROID_LOG_DEBUG,"weijuncheng","resend SIGABRT signal\n");
__android_log_print(ANDROID_LOG_DEBUG,"weijuncheng","resend SIGABRT signal pid = %d\n",getpid());
__android_log_print(ANDROID_LOG_DEBUG,"weijuncheng","resend SIGABRT signal tid = %d\n",gettid());
int rc = syscall(SYS_rt_tgsigqueueinfo, getpid(), gettid(), signal_number, info);
if (rc != 0) {
__android_log_print(ANDROID_LOG_DEBUG,"weijuncheng","fail to resend during crash");
_exit(0);
}
}
extern "C"
JNIEXPORT void JNICALL
Java_com_test_weijuncheng_myapplication_services_IsolatedService_SignalHandlerInit(JNIEnv *env,
jobject instance) {
struct sigaction action;
memset(&action, 0, sizeof(action));
sigemptyset(&action.sa_mask);
action.sa_handler = reinterpret_cast(signal_handler);
action.sa_flags = SA_RESTART | SA_SIGINFO;
action.sa_flags |= SA_ONSTACK;
sigaction(SIGABRT, &action, NULL);
}
extern "C"
JNIEXPORT void JNICALL
Java_com_test_weijuncheng_myapplication_MainActivity_SignalHandlerInit1(JNIEnv *env,
jobject instance) {
//点击到声明上，再点击Alt+Enter即可
// TODO
struct sigaction action;
memset(&action, 0, sizeof(action));
sigemptyset(&action.sa_mask);
action.sa_handler = reinterpret_cast(signal_handler1);
action.sa_flags = SA_RESTART | SA_SIGINFO;
action.sa_flags |= SA_ONSTACK;
sigaction(SIGABRT, &action, NULL);
}
extern "C"
JNIEXPORT void JNICALL
Java_com_test_weijuncheng_myapplication_MainActivity_CreateSignalSIABRT(JNIEnv *env,
jobject instance) {
// TODO
(void) tgkill(getpid(), gettid(), 6); //这个相当于单独发送一个SIGABRT信号
}
AndroidManifest.xml
情况1
原因是这个是SIGABRT(signal 6)发送时在abort中发送了两次
37void abort()
38#endif
39{
40 // Don't block SIGABRT to give any signal handler a chance; we ignore
41 // any errors -- X311J doesn't allow abort to return anyway.
42 sigset_t mask;
43 sigfillset(&mask);
44 sigdelset(&mask, SIGABRT);
45 sigprocmask(SIG_SETMASK, &mask, NULL);
46
47 raise(SIGABRT);
48
49 // If SIGABRT ignored, or caught and the handler returns,
50 // remove the SIGABRT signal handler and raise SIGABRT again.
51 struct sigaction sa;
52 sa.sa_handler = SIG_DFL;
53 sa.sa_flags = SA_RESTART;
54 sigemptyset(&sa.sa_mask);
55 sigaction(SIGABRT, &sa, &sa);//将创建的信号处理函数置空，使信号重新走正常的流程
56 sigprocmask(SIG_SETMASK, &mask, NULL);
57 raise(SIGABRT); //向正在执行的进程发送一个信号
58 _exit(1);
59}
也就是说上面的std::string test1 = NULL;会调用abort函数，发送两次信号，第一次信号被自定义的信号处理函数捕获；第二次再发送一个SIGABRT信号时，会进入默认的信号处理逻辑中，也就可以抓coredump
echo 1 > /d/tracing/events/signal/enable
echo 1 > /d/tracing/tracing_on
cd /d/tracing/
cat trace_pipe
echo 0 > /d/tracing/tracing_on
g.myapplication-18399 [007] d..2 75677.378868: signal_generate: sig=6 errno=0 code=-6 comm=g.myapplication pid=18399 grp=0 res=0
g.myapplication-18399 [007] d..2 75677.378913: signal_deliver: sig=6 errno=0 code=-6 sa_handler=7f5d497664 sa_flags=18000004
g.myapplication-18399 [007] d..2 75677.379146: signal_generate: sig=6 errno=0 code=-6 comm=g.myapplication pid=18399 grp=0 res=0
g.myapplication-18399 [007] d..2 75677.379161: signal_deliver: sig=6 errno=0 code=-6 sa_handler=0 sa_flags=10000000
JDWP-18406 [003] d..2 75677.379409: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
<...>-18410 [000] d..2 75677.379416: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Jit thread pool-18404 [002] d..2 75677.379420: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
<...>-18415 [005] d..2 75677.379424: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
<...>-18417 [004] d..2 75677.379428: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
FileObserver-18416 [007] d..2 75677.379434: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Signal Catcher-18405 [001] d..2 75677.379437: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
FinalizerDaemon-18412 [002] d..2 75677.379451: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Profile Saver-18438 [004] d..2 75677.379453: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
hwuiTask2-18497 [005] d..2 75677.379455: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
ReferenceQueueD-18411 [000] d..2 75677.379458: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
hwuiTask1-18496 [007] d..2 75677.379460: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
FinalizerWatchd-18413 [003] d..2 75677.379465: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Binder:perf-eve-18409 [001] d..2 75677.379467: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
HeapTaskDaemon-18414 [002] d..2 75677.379470: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Binder:intercep-18461 [004] d..2 75677.379473: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
<...>-18793 [005] d..2 75677.379475: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
RenderThread-18491 [006] d..2 75677.379506: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
-0 [001] d.h5 75677.437617: signal_generate: sig=32 errno=0 code=131070 comm=POSIX timer 0 pid=651 grp=0 res=0
-0 [001] d.h5 75677.504817: signal_generate: sig=32 errno=0 code=131070 comm=POSIX timer 0 pid=651 grp=0 res=0
ActivityManager-1621 [002] d..2 75677.761719: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=0
ActivityManager-1621 [002] d..2 75677.766979: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
ActivityManager-1621 [002] d..2 75677.772286: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
perfd-2659 [000] ...1 75677.774504: tracing_mark_write: B|454|perf_lock_acq: send output handle 761 to client(pid 1569, tid=13241)
perfd-2659 [000] ...1 75677.774530: tracing_mark_write: E
ActivityManager-1621 [005] d..2 75677.777591: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
ActivityManager-1621 [000] d..2 75677.782799: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
ActivityManager-1621 [007] d..2 75677.788065: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
ActivityManager-1621 [003] d..2 75677.793299: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
ActivityManager-1621 [000] d..2 75677.798507: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
ActivityManager-1621 [000] d..2 75677.803718: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
ActivityManager-1621 [004] d..2 75677.808966: signal_generate: sig=9 errno=0 code=0 comm=g.myapplication pid=18399 grp=1 res=2
Signal Catcher-18405 [004] d..3 75677.810354: signal_generate: sig=17 errno=0 code=262147 comm=main pid=728 grp=1 res=0
可见，生成了两次signal 6，第一次是有handler的，第二次handler被清零了，则相应进程就被kill了，导致crash闪退
那么为什么case进程没有立即闪退而是等到assertTrue失败了呢？在case中没有立即crash的原因是，crash的是一个Isolated Process服务
class IsolatedServiceConnection implements ServiceConnection {
private IIsolatedService isolatedService;
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
isolatedService = IIsolatedService.Stub.asInterface(service);
try {
isolatedService.CreatewillCrash();
} catch (RemoteException e) {
e.printStackTrace();
}
}
@Override
public void onServiceDisconnected(ComponentName name) {
}
}
Button btn1 = (Button)findViewById(R.id.button1);
btn1.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Log.i("weijuncheng","btn0");
//SignalHandlerInit1();
//CreateWillCrash1();
//CreateSignalSIABRT();
bindService(new Intent(MainActivity.this,IsolatedService.class),new IsolatedServiceConnection(), Context.BIND_AUTO_CREATE);
}
});
点击button时虽然页面没有闪退；但log中还是能看到service crash，die的信息，并且也会生成coredump
情况2
还有一种情况，首先我们将点击按钮换为：
Button btn1 = (Button)findViewById(R.id.button1);
btn1.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Log.i("weijuncheng","btn0");
SignalHandlerInit1();
CreateSignalSIABRT();
}
});
对应的产生信号量和处理信号量的handler为这样时:
extern "C"
JNIEXPORT void JNICALL
Java_com_test_weijuncheng_myapplication_MainActivity_CreateSignalSIABRT(JNIEnv *env,
jobject instance) {
// TODO
(void) tgkill(getpid(), gettid(), 6); //这个相当于单独发送一个SIGABRT信号
}
void signal_handler(int signal_number, siginfo* info, void *){
std::cout<<"weijuncheng handle SIGABRT signal"<页面不会闪退，原因是通过tkill只发送了一次signal 6，被截住了，也不会生成coredump；如果想要正常crash还可以参照abort的写法，将handler改为：
void signal_handler1(int signal_number, siginfo* info, void *){
//std::cout<<"weijuncheng handle SIGABRT signal"<si_code >= 0 || info->si_code == SI_TKILL) {
// rt_tgsigqueueinfo(2)'s documentation appears to be incorrect on kernels
// that contain commit 66dd34a (3.9+). The manpage claims to only allow
// negative si_code values that are not SI_TKILL, but 66dd34a changed the
// check to allow all si_code values in calls coming from inside the house.
}
__android_log_print(ANDROID_LOG_DEBUG,"weijuncheng","resend SIGABRT signal\n");
__android_log_print(ANDROID_LOG_DEBUG,"weijuncheng","resend SIGABRT signal pid = %d\n",getpid());
__android_log_print(ANDROID_LOG_DEBUG,"weijuncheng","resend SIGABRT signal tid = %d\n",gettid());
int rc = syscall(SYS_rt_tgsigqueueinfo, getpid(), gettid(), signal_number, info);
if (rc != 0) {
__android_log_print(ANDROID_LOG_DEBUG,"weijuncheng","fail to resend during crash");
_exit(0);
}
}
那么也会复现上面的trace log；
回到case
我们再看case运行时的trace log：
Binder:28925_3-28943 [002] d..2 83514.980997: signal_generate: sig=31 errno=1 code=458753 comm=Binder:28925_3 pid=28943 grp=0 res=0
Binder:28925_3-28943 [002] d..2 83514.981028: signal_deliver: sig=31 errno=1 code=458753 sa_handler=7f7cd89d5c sa_flags=18000004
Binder:28925_3-28943 [002] d..2 83514.981146: signal_generate: sig=31 errno=1 code=458753 comm=Binder:28925_3 pid=28943 grp=0 res=0
Binder:28925_3-28943 [002] d..2 83514.981154: signal_deliver: sig=31 errno=1 code=458753 sa_handler=0 sa_flags=10000000
Binder:looper-c-28934 [001] d..2 83514.981278: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Binder:28925_2-28940 [005] d..2 83514.981284: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Jit thread pool-28930 [000] d..2 83514.981292: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
JDWP-28932 [002] d..2 83514.981299: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Signal Catcher-28931 [000] d..2 83514.981320: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
ReferenceQueueD-28935 [002] d..2 83514.981322: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
android.os.cts-28925 [005] d..2 83514.981336: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
FinalizerWatchd-28937 [000] dn.2 83514.981367: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Binder:perf-eve-28933 [003] d..2 83514.981373: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
FinalizerDaemon-28936 [005] d..2 83514.981386: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Binder:28925_1-28939 [001] d..2 83514.981460: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
HeapTaskDaemon-28938 [004] d..2 83514.981588: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
FileObserver-28941 [006] d..2 83514.981745: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
和上面demo的trace log类似，因此抓不出tombstone的原因已经清楚了，是定义了信号处理函数，其中comm=Binder:28925_3，28925为信号发送端，pid=28943为信号接收端；且因为走到了后面默认的信号处理逻辑，因此可以通过coredump来查看
而究竟类似上面的情况一，发送端就发送了两次信号；或者情况二，定义的handler做了再次发送的信号；这个需要找到handler才能进一步确认，或者再通过demo生成SIGSYS看是否会发送两次；这就不在本章的讨论范围中了
回到demo 如何根据handler的值查看具体handler
sig=6 errno=0 code=-6 sa_handler=7f5d4967f8 sa_flags=18000004
ps | grep weijuncheng
u0_a169 20189 728 1646708 53452 SyS_epoll_ 7f7bbac540 S com.test.weijuncheng.myapplication
cat /proc/20189/maps > /sdcard/log2.log
或者cat /proc/$(pidof "com.test.weijuncheng.myapplication")/maps
得到的结果是一样的，其中
7f5d486000-7f5d51a000 r-xp 00000000 fd:00 1205999 /data/app/com.test.weijuncheng.myapplication-2/lib/arm64/libnative-lib.so
7f5d51a000-7f5d529000 ---p 00000000 00:00 0
7f5d529000-7f5d52f000 r--p 00093000 fd:00 1205999 /data/app/com.test.weijuncheng.myapplication-2/lib/arm64/libnative-lib.so
7f5d52f000-7f5d530000 rw-p 00099000 fd:00 1205999 /data/app/com.test.weijuncheng.myapplication-2/lib/arm64/libnative-lib.so
只能找到是哪个so，具体映射到哪个地址还是未知的 (objdump只能看到so库中的函数，如果不包含符号表，只能看到全局函数)
backtrace pc，objdump出来的值都是相对地址，其绝对地址需要看被加载到了哪一块内存区域，这是看memory maps，proc/pid/maps来决定的
7f5d4967f8-7f5d486000 = 107F8 相对地址和绝对地址的差别
00000000000107f8 <_Z15signal_handler1iP7siginfoPv@@Base>:
107f8: d10403ff sub sp, sp, #0x100
107fc: a90f7bfd stp x29, x30, [sp,#240]
10800: 9103c3fd add x29, sp, #0xf0
10804: 910103e8 add x8, sp, #0x40
10808: d53bd049 mrs x9, tpidr_el0
1080c: f9401529 ldr x9, [x9,#40]
10810: f9000109 str x9, [x8]
10814: b90067e0 str w0, [sp,#100]
10818: f9002fe1 str x1, [sp,#88]
1081c: f9002be2 str x2, [sp,#80]
10820: b0000301 adrp x1, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
10824: 913bc421 add x1, x1, #0xef1
10828: b0000302 adrp x2, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
1082c: 913b6c42 add x2, x2, #0xedb
10830: 320007e0 orr w0, wzr, #0x3
10834: f9001fe8 str x8, [sp,#56]
10838: 97fffd1a bl fca0 <__android_log_print@plt>
1083c: aa1f03e8 mov x8, xzr
10840: b94067ea ldr w10, [sp,#100]
10844: b90037e0 str w0, [sp,#52]
10848: 2a0a03e0 mov w0, w10
1084c: aa0803e1 mov x1, x8
10850: 97fffcb4 bl fb20
10854: f9402fe8 ldr x8, [sp,#88]
10858: f90017e0 str x0, [sp,#40]
1085c: b50001e8 cbnz x8, 10898 <_Z15signal_handler1iP7siginfoPv@@Base+0xa0>
10860: 2a1f03e8 mov w8, wzr
10864: b27903e2 orr x2, xzr, #0x80
10868: 9101a3e9 add x9, sp, #0x68
1086c: aa0903e0 mov x0, x9
10870: 53001d01 uxtb w1, w8
10874: 97fffd47 bl fd90
10878: b90073ff str wzr, [sp,#112]
1087c: 97fffc7d bl fa70
10880: b9007be0 str w0, [sp,#120]
10884: 97fffd67 bl fe20
10888: 9101a3e9 add x9, sp, #0x68
1088c: b9007fe0 str w0, [sp,#124]
10890: f9002fe9 str x9, [sp,#88]
10894: 1400000a b 108bc <_Z15signal_handler1iP7siginfoPv@@Base+0xc4>
10898: f9402fe8 ldr x8, [sp,#88]
1089c: b9400909 ldr w9, [x8,#8]
108a0: 36f800a9 tbz w9, #31, 108b4 <_Z15signal_handler1iP7siginfoPv@@Base+0xbc>
108a4: f9402fe8 ldr x8, [sp,#88]
108a8: b9400909 ldr w9, [x8,#8]
108ac: 3100193f cmn w9, #0x6
108b0: 54000041 b.ne 108b8 <_Z15signal_handler1iP7siginfoPv@@Base+0xc0>
108b4: 14000001 b 108b8 <_Z15signal_handler1iP7siginfoPv@@Base+0xc0>
108b8: 14000001 b 108bc <_Z15signal_handler1iP7siginfoPv@@Base+0xc4>
108bc: b0000301 adrp x1, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
108c0: 913bc421 add x1, x1, #0xef1
108c4: b0000302 adrp x2, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
108c8: 913c5c42 add x2, x2, #0xf17
108cc: 320007e0 orr w0, wzr, #0x3
108d0: 97fffcf4 bl fca0 <__android_log_print@plt>
108d4: b90027e0 str w0, [sp,#36]
108d8: 97fffc66 bl fa70
108dc: b0000301 adrp x1, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
108e0: 913bc421 add x1, x1, #0xef1
108e4: b0000302 adrp x2, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
108e8: 913cb842 add x2, x2, #0xf2e
108ec: 320007e8 orr w8, wzr, #0x3
108f0: b90023e0 str w0, [sp,#32]
108f4: 2a0803e0 mov w0, w8
108f8: b94023e3 ldr w3, [sp,#32]
108fc: 97fffce9 bl fca0 <__android_log_print@plt>
10900: b9001fe0 str w0, [sp,#28]
10904: 97fffc9b bl fb70
10908: b0000301 adrp x1, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
1090c: 913bc421 add x1, x1, #0xef1
10910: b0000302 adrp x2, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
10914: 913d3842 add x2, x2, #0xf4e
10918: 320007e8 orr w8, wzr, #0x3
1091c: b9001be0 str w0, [sp,#24]
10920: 2a0803e0 mov w0, w8
10924: b9401be3 ldr w3, [sp,#24]
10928: 97fffcde bl fca0 <__android_log_print@plt>
1092c: b90017e0 str w0, [sp,#20]
10930: 97fffc50 bl fa70
10934: b90013e0 str w0, [sp,#16]
10938: 97fffc8e bl fb70
1093c: b94067e3 ldr w3, [sp,#100]
10940: f9402fe4 ldr x4, [sp,#88]
10944: 321c0fe8 orr w8, wzr, #0xf0
10948: 2a0803e1 mov w1, w8
1094c: b9000fe0 str w0, [sp,#12]
10950: aa0103e0 mov x0, x1
10954: b94013e1 ldr w1, [sp,#16]
10958: b9400fe2 ldr w2, [sp,#12]
1095c: 97fffd09 bl fd80
10960: 2a0003e8 mov w8, w0
10964: b9004fe8 str w8, [sp,#76]
10968: b9404fe8 ldr w8, [sp,#76]
1096c: 34000168 cbz w8, 10998 <_Z15signal_handler1iP7siginfoPv@@Base+0x1a0>
10970: b0000301 adrp x1, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
10974: 913bc421 add x1, x1, #0xef1
10978: b0000302 adrp x2, 71000 <_ZSt15get_new_handlerv@@Base+0x3a60>
1097c: 913db842 add x2, x2, #0xf6e
10980: 320007e0 orr w0, wzr, #0x3
10984: 97fffcc7 bl fca0 <__android_log_print@plt>
10988: 2a1f03e8 mov w8, wzr
1098c: b9000be0 str w0, [sp,#8]
10990: 2a0803e0 mov w0, w8
10994: 97fffda7 bl 10030 <_exit@plt>
10998: d53bd048 mrs x8, tpidr_el0
1099c: f9401508 ldr x8, [x8,#40]
109a0: f9401fe9 ldr x9, [sp,#56]
109a4: f940012a ldr x10, [x9]
109a8: eb0a011f cmp x8, x10
109ac: 54000081 b.ne 109bc <_Z15signal_handler1iP7siginfoPv@@Base+0x1c4>
109b0: a94f7bfd ldp x29, x30, [sp,#240]
109b4: 910403ff add sp, sp, #0x100
109b8: d65f03c0 ret
109bc: 97fffda5 bl 10050 <__stack_chk_fail@plt>
通过地址找到了handler
查看case的handler在/system/bin/linker64中，但是搜索相关路径没有SIGSYS字样，还是有点奇怪，且linker64不是一个so库，而是一个可执行bin文件，如何objdump?
aarch64-linux-android-objdump -D -m arm linker64 > link64.log (不要加-b)
Binder:17173_2-17188 [000] d..2 166977.353618: signal_generate: sig=31 errno=1 code=458753 comm=Binder:17173_2 pid=17188 grp=0 res=0
Binder:17173_2-17188 [000] d..2 166977.353658: signal_deliver: sig=31 errno=1 code=458753 sa_handler=7f7cd89d5c sa_flags=18000004
Binder:17173_2-17188 [000] d..2 166977.353818: signal_generate: sig=31 errno=1 code=458753 comm=Binder:17173_2 pid=17188 grp=0 res=0
Binder:17173_2-17188 [000] d..2 166977.353827: signal_deliver: sig=31 errno=1 code=458753 sa_handler=0 sa_flags=10000000
首先找到handler在进程中的地址
Start proc 17173:android.os.cts/u0i56 for service android.os.cts/.SeccompTest$IsolatedService caller=android.os.cts 17188 接收进程
11-23 10:42:28.568 17188 17188 I Binder:17173_2: type=1400 audit(0.0:39265): avc: denied { write } for name="core" dev="dm-0" ino=675953 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
11-23 10:42:28.568 17188 17188 I Binder:17173_2: type=1400 audit(0.0:39266): avc: denied { add_name } for name="!system!bin!app_process64.17173.Binder:17173_2" scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
11-23 10:42:28.568 17188 17188 I Binder:17173_2: type=1400 audit(0.0:39267): avc: denied { create } for name="!system!bin!app_process64.17173.Binder:17173_2" scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0:c512,c768 tclass=file permissive=1
11-23 10:42:28.568 17188 17188 I Binder:17173_2: type=1400 audit(0.0:39268): avc: denied { write } for path="/data/core/!system!bin!app_process64.17173.Binder:17173_2" dev="dm-0" ino=675963 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0:c512,c768 tclass=file permissive=1
cat /proc/$(pidof "android.os.cts")/maps
7f7cd83000-7f7ce2c000 r-xp 00000000 b3:18 749 /system/bin/linker64
7f7ce2c000-7f7ce2d000 r--p 00000000 00:00 0 [anon:atexit handlers]
7f7ce2d000-7f7ce30000 r--p 000a9000 b3:18 749 /system/bin/linker64
7f7ce30000-7f7ce31000 rw-p 000ac000 b3:18 749 /system/bin/linker64
7f7cd89d5c-7f7cd83000 = 6D5C
然后查找6D5C
0000000000006d5c <__dl__ZL24debuggerd_signal_handleriP7siginfoPv>:
6d5c: a9bb67fa ldmibge fp!, {r1, r3, r4, r5, r6, r7, r8, r9, sl, sp, lr}
6d60: a9015ff8 stmdbge r1, {r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, lr}
6d64: a90257f6 stmdbge r2, {r1, r2, r4, r5, r6, r7, r8, r9, sl, ip, lr}
6d68: a9034ff4 stmdbge r3, {r2, r4, r5, r6, r7, r8, r9, sl, fp, lr}
6d6c: a9047bfd stmdbge r4, {r0, r2, r3, r4, r5, r6, r7, r8, r9, fp, ip, sp, lr}
6d70: 910103fd strdls r0, [r1, -sp]
6d74: d10303ff strdle r0, [r3, -pc]
但是在其中加log根本没有被调用的迹象，这个相当奇怪；为了防止计算有误，这里还将注册的SIGSYS语句注释掉重新跑了一遍，再看signal trace log
Binder:7495_3-7514 [000] d..2 198.369068: signal_generate: sig=31 errno=1 code=458753 comm=Binder:7495_3 pid=7514 grp=0 res=0
Binder:7495_3-7514 [000] d..2 198.369097: signal_deliver: sig=31 errno=1 code=458753 sa_handler=0 sa_flags=0
<...>-7510 [005] d..2 198.369218: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
Signal Catcher-7501 [000] d..2 198.369230: signal_deliver: sig=9 errno=0 code=0 sa_handler=0 sa_flags=0
发现果然handler相关的log没有了；
那么问题就变为，为什么注册了信号处理函数，在trace log中也打出来了，但好像并没有执行；添加的log没打出来，且最后没有生成tombstone
总结
当信号量被注册了自定义的信号处理函数时，无法tombstone，但是可能可以获取coredump，需要具体问题具体分析了；目前的问题变为了注册了信号处理函数但不执行；这个待续，目前有两个思路 1.signal被ignore或者blocker 2.信号从内核传递到用户态的信号处理函数时出现了问题，待进一步分析