網站首頁編程語言正文

Android開發中Signal背后的bug與解決_Android

作者：Pika ? 更新時間： 2022-12-24 編程語言

背景

熟悉我的老朋友可能都知道，之前為了應對crash與anr，開源過一個“民間偏方”的庫Signal，用于解決在發生crash或者anr時進行應用的重啟，從而最大程度減少其壞影響。

在維護的過程中，發生過這樣一件趣事，就是有位朋友發現在遇到信號為SIGSEGV時，再調用信號處理函數的時候

void SigFunc(int sig_num, siginfo *info, void *ptr) {
    // 這里判空并不代表這個對象就是安全的，因為有可能是臟內存
    if (currentEnv == nullptr || currentObj == nullptr) {
        return;
    }
    __android_log_print(ANDROID_LOG_INFO, TAG, "%d catch", sig_num);
    __android_log_print(ANDROID_LOG_INFO, TAG, "crash info pid:%d ", info->si_pid);
    jclass main = currentEnv->FindClass("com/example/lib_signal/SignalController");
    jmethodID id = currentEnv->GetMethodID(main, "callNativeException", "(ILjava/lang/String;)V");
    if (!id) {
        __android_log_print(ANDROID_LOG_INFO, TAG, "%d !id!id!id!id!id!id!id", sig_num);
        return;
    }
    __android_log_print(ANDROID_LOG_INFO, TAG, "%d 11111111111111111111", sig_num);
    jstring nativeStackTrace  = currentEnv->NewStringUTF(backtraceToLogcat().c_str());
    __android_log_print(ANDROID_LOG_INFO, TAG, "%d 22222222222222222222", sig_num);
    currentEnv->CallVoidMethod(currentObj, id, sig_num, nativeStackTrace);
    __android_log_print(ANDROID_LOG_INFO, TAG, "%d 33333333333333333333", sig_num);
    // 釋放資源
    currentEnv->DeleteGlobalRef(currentObj);
    currentEnv->DeleteLocalRef(nativeStackTrace);
}

會遇到

從上文打印中看到，SIGSEGV被拋出，之后被我們的信號處理函數抓到了，但是卻沒有被回調到java層，反而變成了SIGABRT。還有就是SIGSEGV被捕獲后，卻無法通過jni回調給java層的重啟處理。本文將從這個例子出發，從踩坑的過程中去學習更多jni知識。

出現SIGABRT的原因

首先呢，currentEnv是一個全局的變量，我們一般jni開發的時候，都習慣于保存一個JNIEnv全局的引用，用于后續的調用處理！但是！這樣其實是一個風險的操作，比如我們在sigaction注冊一個信號處理函數的時候，那么當信號來的時候，我們的信號處理運行在哪個線程呢？

答案是：不確定。當信號處理時，會根據當前內核的調度，可能會在當前發出信號的線程中進行處理，同時也可能會另外開出一個線程進行處理。而我們的JNIEnv，它其實是一個線程相關的資源，或者說是線程本地資源（TLS），如果我們在其他線程中調用到這個JNIEnv，那么會怎么樣呢？比如上面例子中的currentEnv，創建在我們的java層的main線程，此時在信號處理函數中調用currentEnv->FindClass，那么不好意思，這個可不屬于當前線程的資源，因此linux內核就會發出一個SIGABRT信號，提示著這個操作將被阻斷

java_vm_ext.cc 
void JavaVMExt::JniAbort(const char* jni_function_name, const char* msg) {
    Thread* self = Thread::Current();
    ScopedObjectAccess soa(self);
    ArtMethod* current_method = self->GetCurrentMethod(nullptr);
    std::ostringstream os;
    os << "JNI DETECTED ERROR IN APPLICATION: " << msg;
    if (jni_function_name != nullptr) {
        os << "\n    in call to " << jni_function_name;
    }
    // TODO: is this useful given that we're about to dump the calling thread's stack?
    if (current_method != nullptr) {
        os << "\n    from " << current_method->PrettyMethod();
    }
    if (check_jni_abort_hook_ != nullptr) {
        check_jni_abort_hook_(check_jni_abort_hook_data_, os.str());
    } else {
        // Ensure that we get a native stack trace for this thread.
        ScopedThreadSuspension sts(self, ThreadState::kNative);
        LOG(FATAL) << os.str();
        UNREACHABLE();
    }
}

JniAbort 調用會在所有的方法調用前進行檢測，如果使用到了其他線程的JNIEnv，就會發出SIGABRT信號并打印堆棧信息，用于排查

java_vm_ext.cc:578] 
JNI DETECTED ERROR IN APPLICATION: 
thread Thread[3,tid=22651,Native,Thread*=0xb400007c96340270,peer=0x12c4d1a0,"Thread-3"] 
using JNIEnv* from thread Thread[1,tid=22160,Runnable,Thread*=0xb400007c9630dbe0,peer=0x73467b00,"main"]

那么如果我們真的有場景需要通過在信號處理函數中調用到JNIEnv怎么辦，其實也很簡單，通過javaVm重新獲取一個JNIEnv即可，javaVm保證是虛擬機中唯一的，因此可以放在全局變量中，當我們想要在信號處理函數時調用到jni方法，可重新獲取當前線程的環境

信號處理函數中

if (javaVm->GetEnv((void **) &currentEnv, JNI_VERSION_1_4) != JNI_OK) {
    return ;
}

SIGSEGV被捕獲但是調用jni無法進行

我們的例子是這樣的，在java層調用一個jni函數，這個函數通過raise調用向自身發送一個SIGSEGV信號

raise(SIGSEGV);

此時我們的信號處理函數能夠捕獲到這個事件，但是通過currentEnv->CallVoidMethod卻無法調用相應的java層方法了，同時log中出現一個StackOverflowError

Process: com.example.signal, PID: 24575
java.lang.StackOverflowError: stack size 8192KB
	at com.example.signal.MainActivity.throwNativeCrash(Native Method)
	at com.example.signal.MainActivity.onCreate$lambda-0(MainActivity.kt:23)
	at com.example.signal.MainActivity.$r8$lambda$__atZomnwlT46HKNaZgatRAAqwU(Unknown Source:0)
	at com.example.signal.MainActivity$$ExternalSyntheticLambda0.onClick(Unknown Source:2)
	at android.view.View.performClick(View.java:8160)

那么這個究竟是怎么一回事呢？

首先我們要明白，我們真的是因為棧內存耗盡了出現StackOverflowError了嗎？當然不是！我們只是在jni向自己線程發出了一個SIGSEGV信號罷了，怎么跟棧溢出扯上關系了？我們從art虛擬機開始說起

在art虛擬機中，出現SIGSEGV時，會默認先回調這個方法

# fault_handler.cc
// Signal handler called on SIGSEGV.
static bool art_fault_handler(int sig, siginfo_t* info, void* context) {
    return fault_manager.HandleFault(sig, info, context);
}

核心是方法

bool FaultManager::HandleFault(int sig, siginfo_t* info, void* context) {
    if (VLOG_IS_ON(signals)) {
        PrintSignalInfo(VLOG_STREAM(signals) << "Handling fault:" << "\n", info);
    }
#ifdef TEST_NESTED_SIGNAL
    // Simulate a crash in a handler.
  raise(SIGSEGV);
#endif
    針對生成機器碼處理
    if (IsInGeneratedCode(info, context, true)) {
        VLOG(signals) << "in generated code, looking for handler";
        for (const auto& handler : generated_code_handlers_) {
            VLOG(signals) << "invoking Action on handler " << handler;
            if (handler->Action(sig, info, context)) {
                // We have handled a signal so it's time to return from the
                // signal handler to the appropriate place.
                return true;
            }
        }
    }
    // We hit a signal we didn't handle.  This might be something for which
    // we can give more information about so call all registered handlers to
    // see if it is.
    其他非機器碼處理
    if (HandleFaultByOtherHandlers(sig, info, context)) {
        return true;
    }
    // Set a breakpoint in this function to catch unhandled signals.
    只是打印了一些log
    art_sigsegv_fault();
    return false;
}

我們可以留意到，在上面有這么一個判斷IsInGeneratedCode，如果是則嘗試遍歷generated_code_handlers_里面的handler對信號處理，那么IsInGeneratedCode是個啥？其實它是指dex字節碼編譯成機器碼這些代碼，art虛擬會在編譯成機器碼的時候，生成一些虛擬機相關的指令，因此如果SIGSEGV是在這些機器碼中生成的，那么就要通過generated_code_handlers_里面的處理器去處理，同時如果是非機器碼生成的，則走到HandleFaultByOtherHandlers方法中進行處理

bool FaultManager::HandleFaultByOtherHandlers(int sig, siginfo_t* info, void* context) {
    if (other_handlers_.empty()) {
        return false;
    }
    Thread* self = Thread::Current();
    DCHECK(self != nullptr);
    DCHECK(Runtime::Current() != nullptr);
    DCHECK(Runtime::Current()->IsStarted());
    for (const auto& handler : other_handlers_) {
        if (handler->Action(sig, info, context)) {
            return true;
        }
    }
    return false;
}

因此我們特別關注一下generated_code_handlers_，other_handlers_（針對默認處理），它們都是一個集合std::vector<FaultHandler*> 我們看到它的添加元素方法，在FaultManager::AddHandler中

void FaultManager::AddHandler(FaultHandler* handler, bool generated_code) {
    DCHECK(initialized_);
    if (generated_code) {
        generated_code_handlers_.push_back(handler);
    } else {
        other_handlers_.push_back(handler);
    }
}

這里面添加的handler都是FaultHandler的子類，分別是NullPointerHandler，SuspensionHandler，StackOverflowHandler，JavaStackTraceHandler

雖然JavaStackTraceHandler被加入到了other_handlers_，但是依舊會判斷是否處于虛擬機code中

在這里我們明白了SIGSEGV虛擬機的默認處理，一般SIGSEGV都會進入上述handler的判斷，如果滿足了條件就會先執行（之后才執行到我們的信號處理函數，如果系統棧溢出，那么有可能執行不到自己的信號處理器）。本例子中raise(SIGSEGV)向自己的線程拋出了SIGSEGV，如果信號處理器中沒有采用Call系列調用到java層的話，那也不會有問題。

如果調用到了java層，那么就以棧溢出的形式打印log并重新發一個信號值為SIGKILL的信號殺死當前進程。（這里一直有個疑惑點，目前還沒在art源碼上看到為什么會這樣，如果有知道的大佬可勞煩告知）

Sending signal. PID: 29066 SIG: 9

解決方法也比較簡單，當我們異常處理器無法在棧異常情況下，我們可以事先采用sigaltstack分配一塊棧空間

stack_t ss;
if(NULL == (ss.ss_sp = calloc(1, SIGNAL_CRASH_STACK_SIZE))){
    Handle_Exception();
    break;
}
ss.ss_size  = SIGNAL_CRASH_STACK_SIZE;
ss.ss_flags = 0;
if(0 != sigaltstack(&ss, NULL)) {
    Handle_Exception();
    break;
}

同時設置flag為SA_ONSTACK即可，讓信號處理函數有一個安全的棧空間，得以進行后續調用

sigc.sa_flags = SA_SIGINFO|SA_ONSTACK;

小結

本次算是一個記錄，以一個現象例子，更深入了解jni調用，希望讀者有所收獲，最后繼續貼一下項目地址，如果有更多好點子的話，請多多pr！

github.com/TestPlanB/S…

原文鏈接：https://juejin.cn/post/7170261352022294541

上一篇：Docker自定義網絡詳解_docker
下一篇：Docker中redis安裝及測試教程_docker

日本免费高清视频-国产福利视频导航-黄色在线播放国产-天天操天天操天天操天天操|www.shdianci.com

網站首頁編程語言正文

Android開發中Signal背后的bug與解決_Android

目錄

背景

出現SIGABRT的原因

SIGSEGV被捕獲但是調用jni無法進行

小結

相關推薦

日本免费高清视频-国产福利视频导航-黄色在线播放国产-天天操天天操天天操天天操|www.shdianci.com

網站首頁 編程語言 正文

Android開發中Signal背后的bug與解決_Android

目錄

背景

出現SIGABRT的原因

SIGSEGV被捕獲但是調用jni無法進行

小結

相關推薦

網站首頁編程語言正文