如何调试Logcat中出现的Fatal signal 11 (SIGSEGV)崩溃异常

Hey there, let's walk through how to tackle this crash even though you aren't using NDK in your project. First, let's demystify the error you're seeing:

Fatal signal 11 (SIGSEGV), code 1, fault addr 0x6d in tid 2058 (ModernAsyncTask)
[ 03-16 13:36:48.406 607: 607 W/] debuggerd: handling request: pid=1940 uid=10343 gid=10343 tid=2058

A SIGSEGV (Segmentation Fault) means the app tried to access invalid memory. Even if you don't write native code yourself, this can happen because:

• Third-party libraries (like image loaders, network SDKs, maps, etc.) often include precompiled native code (.so files) under the hood.
• System Android APIs you're calling might have native implementations that hit a bug.
• The crash is happening in ModernAsyncTask, a variant of Android's AsyncTask, so the issue is tied to background work your app is doing.

Here's a step-by-step debugging plan:

1. Pinpoint the Crash Context #

First, gather basic details to narrow things down:

• What exact user action triggers the crash? (e.g., tapping a button, loading a screen)
• Does it happen on specific devices or Android versions? (e.g., only Android 10, or only Samsung devices)
• Is it consistent, or intermittent?

2. Audit Your Third-Party Dependencies #

Check all libraries you're using (via build.gradle or imported AAR/JAR files) for native components:

• Look for .so files in your app's build output (usually under app/build/intermediates/merged_native_libs) — these indicate native code is present.
• Review documentation for each dependency: many popular libraries (like Glide, OkHttp, or Firebase) use NDK under the hood. Note which ones are active around the time of the crash.

3. Enable Native Debugging in Android Studio #

Even without your own NDK code, you can debug native crashes:

1. Go to Run > Edit Configurations
2. Select your app's configuration
3. Switch to the Debugger tab
4. Check the Native box under "Debug type"
5. Rerun your app in debug mode. When the crash happens, Android Studio will show the native call stack, pointing you to which library or system function is failing.

4. Capture Full Native Stack Traces #

If you can't catch the crash in debug mode, use adb to get detailed logs:

adb logcat -v long > crash_log.txt

This will save a full log including the native stack trace. Even without debug symbols, you'll see the name of the native library causing the crash (e.g., libglide.so or libandroid_runtime.so), which is critical for narrowing down the issue.

5. Inspect Your ModernAsyncTask Logic #

Even though the crash is native, it might be triggered by a Java-layer mistake:

• Are you passing null to a system API or third-party method that expects a non-null value? (e.g., a bitmap that's already recycled)
• Are you accessing UI elements directly from the doInBackground method? (This can cause unexpected memory issues)
• Is the data you're processing in the background being modified or destroyed by the main thread while the task runs?

6. Minimize and Isolate the Issue #

Try to create a minimal reproduction case:

• Remove non-essential dependencies one by one to see if the crash stops.
• Strip down the ModernAsyncTask code to only the core logic that triggers the crash.
  This helps you confirm whether the issue is tied to a specific library or your own code.

7. Check for System/Device-Specific Bugs #

Some SIGSEGV crashes are caused by Android OS bugs or device-specific quirks. Search for the error code, fault address, and affected library along with your target Android version — other developers might have reported similar issues with workarounds.

内容的提问来源于stack exchange，提问作者Mohammed Abdul Bari