首先，获得你的墓碑堆栈跟踪，它将打印每次你的应用程序崩溃。就像这样:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'XXXXXXXXX'
pid: 1658, tid: 13086  >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e
 r0 00000000  r1 00000001  r2 ad12d1e8  r3 7373654d
 r4 64696f72  r5 00000406  r6 00974130  r7 40d14008
 r8 4b857b88  r9 4685adb4  10 00974130  fp 4b857ed8
 ip 00000000  sp 4b857b50  lr afd11108  pc ad115ebc  cpsr 20000030
 d0  4040000040000000  d1  0000004200000003
 d2  4e72cd924285e370  d3  00e81fe04b1b64d8
 d4  3fbc71c7009b64d8  d5  3fe999999999999a
 d6  4010000000000000  d7  4000000000000000
 d8  4000000000000000  d9  0000000000000000
 d10 0000000000000000  d11 0000000000000000
 d12 0000000000000000  d13 0000000000000000
 d14 0000000000000000  d15 0000000000000000
 scr 80000012

         #00  pc 000108d8  /system/lib/libc.so
         #01  pc 0003724c  /system/lib/libxvi020.so
         #02  pc 0000ce02  /system/lib/libxvi020.so
         #03  pc 0000d672  /system/lib/libxvi020.so
         #04  pc 00010cce  /system/lib/libxvi020.so
         #05  pc 00004432  /system/lib/libwimax_jni.so
         #06  pc 00011e74  /system/lib/libdvm.so
         #07  pc 0004354a  /system/lib/libdvm.so
         #08  pc 00017088  /system/lib/libdvm.so
         #09  pc 0001c210  /system/lib/libdvm.so
         #10  pc 0001b0f8  /system/lib/libdvm.so
         #11  pc 00059c24  /system/lib/libdvm.so
         #12  pc 00059e3c  /system/lib/libdvm.so
         #13  pc 0004e19e  /system/lib/libdvm.so
         #14  pc 00011b94  /system/lib/libc.so
         #15  pc 0001173c  /system/lib/libc.so

code around pc:
ad115e9c 4620eddc bf00bd70 0001736e 0001734e 
ad115eac 4605b570 447c4c0a f7f44620 e006edc8 
ad115ebc 42ab68e3 68a0d103 f7f42122 6864edd2 
ad115ecc d1f52c00 44784803 edbef7f4 bf00bd70 
ad115edc 00017332 00017312 2100b51f 46682210 

code around lr:
afd110e8 e2166903 1a000018 e5945000 e1a02004 
afd110f8 e2055a02 e1a00005 e3851001 ebffed92 
afd11108 e3500000 13856002 1a000001 ea000009 
afd11118 ebfffe50 e1a01004 e1a00006 ebffed92 
afd11128 e1a01005 e1550000 e1a02006 e3a03000 

stack:
    4b857b10  40e43be8  
    4b857b14  00857280  
    4b857b18  00000000  
    4b857b1c  034e8968  
    4b857b20  ad118ce9  /system/lib/libnativehelper.so
    4b857b24  00000002  
    4b857b28  00000406

然后，使用addr2line实用程序(在NDK工具链中找到它)来查找崩溃的函数。在本例中，您需要这样做

addr2line -e -f libc.so 0001173c

你会发现问题出在哪里。当然，这不会帮助你，因为它是在libc。

因此，您可以结合使用arm-eabi-objdump的实用程序来找到最终目标。

相信我，这是一项艰巨的任务。

---

---

---

只是为了了解最新情况。我想我从整个源代码树开始做Android原生构建已经有很长一段时间了，直到今天我自己仔细阅读了NDK文档。自发布NDK-r6以来，它提供了一个名为ndk-stack的实用程序。

以下是NDK官方文档中的NDK-r9焦油球内容。

概述:

Ndk-stack是一个简单的工具，允许您过滤堆栈跟踪，因为它们出现在'adb logcat'的输出中，并用相应的:值替换共享库中的任何地址。

简而言之，它将翻译为:

  I/DEBUG   (   31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
  I/DEBUG   (   31): Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
  I/DEBUG   (   31): pid: 351, tid: 351  %gt;%gt;%gt; /data/local/ndk-tests/crasher <<<
  I/DEBUG   (   31): signal 11 (SIGSEGV), fault addr 0d9f00d8
  I/DEBUG   (   31):  r0 0000af88  r1 0000a008  r2 baadf00d  r3 0d9f00d8
  I/DEBUG   (   31):  r4 00000004  r5 0000a008  r6 0000af88  r7 00013c44
  I/DEBUG   (   31):  r8 00000000  r9 00000000  10 00000000  fp 00000000
  I/DEBUG   (   31):  ip 0000959c  sp be956cc8  lr 00008403  pc 0000841e  cpsr 60000030
  I/DEBUG   (   31):          #00  pc 0000841e  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #01  pc 000083fe  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #02  pc 000083f6  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #03  pc 000191ac  /system/lib/libc.so
  I/DEBUG   (   31):          #04  pc 000083ea  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #05  pc 00008458  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #06  pc 0000d362  /system/lib/libc.so
  I/DEBUG   (   31):

进入更具可读性的输出:

  ********** Crash dump: **********
  Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
  pid: 351, tid: 351  >>> /data/local/ndk-tests/crasher <<<
  signal 11 (SIGSEGV), fault addr 0d9f00d8
  Stack frame #00  pc 0000841e  /data/local/ndk-tests/crasher : Routine zoo in /tmp/foo/crasher/jni/zoo.c:13
  Stack frame #01  pc 000083fe  /data/local/ndk-tests/crasher : Routine bar in /tmp/foo/crasher/jni/bar.c:5
  Stack frame #02  pc 000083f6  /data/local/ndk-tests/crasher : Routine my_comparison in /tmp/foo/crasher/jni/foo.c:9
  Stack frame #03  pc 000191ac  /system/lib/libc.so
  Stack frame #04  pc 000083ea  /data/local/ndk-tests/crasher : Routine foo in /tmp/foo/crasher/jni/foo.c:14
  Stack frame #05  pc 00008458  /data/local/ndk-tests/crasher : Routine main in /tmp/foo/crasher/jni/main.c:19
  Stack frame #06  pc 0000d362  /system/lib/libc.so

用法:

为此，首先需要一个目录，其中包含应用程序共享库的符号版本。如果你使用NDK构建系统(即NDK -build)，那么这些总是位于$PROJECT_PATH/obj/local/下，其中代表你设备的ABI(即默认情况下的armeabi)。

你可以将logcat文本作为程序的直接输入，例如:

adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

或者你可以使用-dump选项指定logcat作为输入文件，例如:

adb logcat > /tmp/foo.txt
$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt

重要的是:

该工具在logcat输出中寻找包含开始的初始行，即看起来像这样:

 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

当复制/粘贴跟踪时，不要忘记跟踪中的这一行，否则ndk-stack将无法正常工作。

快乐吗?

未来版本的ndk-stack将尝试启动adb logcat并自动选择库路径。现在，您必须手动执行这些步骤。

到目前为止，ndk-stack不处理没有调试信息的库。尝试检测到给定PC地址的最近函数入口点可能是有用的(例如在libc中)。上面的例子)。

我发现了问题所在。我不认为这将帮助许多人试图追踪他们的个人SIGSEGV，但我的(这是非常困难的)完全与此相关:

https://code.google.com/p/android/issues/detail?id=8709

libcrypto。所以在我的垃圾堆里找到了线索。当我试图确定我是否已经看到数据包时，我对数据包数据进行MD5哈希，如果我已经看到了，就跳过它。我一度认为这是一个与跟踪这些散列相关的丑陋的线程问题，但事实证明这是java.security. messagdigest类!它不是线程安全的!

我根据设备UUID和时间戳在每个包中填充了一个UID。从那以后就没有问题了。

I guess the lesson I can impart to those that were in my situation is, even if you're a 100% Java application, pay attention to the native library and symbol noted in the crash dump for clues. Googling for SIGSEGV + the lib .so name will go a lot farther than the useless code=1, etc... Next think about where your Java app could touch native code, even if it's nothing you're doing. I made the mistake of assuming it was a Service + UI threading issue where the Canvas was drawing something that was null, (the most common case I Googled on SIGSEGV) and ignored the possibility it could have been completely related to code I wrote that was related to the lib .so in the crash dump. Naturally java.security would use a native component in libcrypto.so for speed, so once I clued in, I Googled for Android + SIGSEGV + libcrypto.so and found the documented issue.

我也得到了这个错误很多次，我解决了它。 在本机进行内存管理时将会遇到此错误。

Your application is accessing memory outside of its address space. This is most likely an invalid pointer access. SIGSEGV = segmentation fault in native code. Since it is not occurring in Java code you won't see a stack trace with details. However, you may still see some stack trace information in the logcat if you look around a bit after the application process crashes. It will not tell you the line number within the file, but will tell you which object files and addresses were in use in the call chain. From there you can often figure out which area of the code is problematic. You can also setup a gdb native connection to the target process and catch it in the debugger.

我得到这个错误通过保存一个对象到共享首选项作为一个gson转换字符串。gson String是不好的，所以检索和反序列化对象实际上不能正确工作。这意味着对该对象的任何后续访问都会导致此错误。可怕的:)

当使用这样的位图时，我得到了这个错误:

bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);

为我解决的问题是减少位图的大小(>1000px高到700px)。

我在Android 4.4.4 (Nexuses，三星)上遇到过SIGSEGV 事实证明，致命错误是在使用DecimalFormat解析空字符串时

 static DecimalFormat decimalFormat = new DecimalFormat("###,###.###");
 void someMethod(String value) {
...
    Number number = decimalFormat.parse(value);//value is null, SIGSEGV will happen`
...
}

在Android > 21上，它成功地处理了try/catch

当我试图访问onDraw()外部的“画布”时，我遇到了这个错误

    private Canvas canvas;

    @Override
    protected void onDraw(Canvas canvas) {
        this.canvas = canvas;
        ....... }

    private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
        @Override
        public boolean onScale(ScaleGestureDetector detector) { 
            canvas.save(); // here

一个非常糟糕的做法:/

检查JNI/本机代码。我的一个引用是空的，但它是间歇性的，所以不是很明显。

试着在你的清单中禁用Android硬件加速。

android:hardwareAccelerated="false"

今天我遇到了致命信号11 (SIGSEGV)，代码1,tid 18161问题中的故障地址0x8，我挣扎了半天来解决这个问题。

我尝试了很多东西，清除缓存和删除。gradle文件和所有。

最后，我禁用即时运行，现在我不会再得到这个问题。 现在我的应用程序是工作后启用即时运行也。这可能是即时运行问题，尝试禁用和启用即时运行

从这个答案可以看出:

进入Android Studio设置或首选项(MAC) ->构建，执行，部署->即时运行。 然后取消选中顶部的“启用即时运行”复选框。

如果您正在使用vitamio库并发生此致命错误。

然后确保在你的项目中gradle targetSdkVersion必须小于23。

检查本机函数是否正常返回，如果不返回请添加返回语句。

在我的案例中，这个问题是由Android Profiler引起的。在Android Studio中，点击“Android Profiler”和“end session”。

具有讽刺意味的是，它还在应用程序中导致了极端的性能问题。

对我来说，这个问题是由于两个活动之间的糟糕演员。 我最近把这个方法从Activity1移到了另一个2。 这样做时，重构会保留这个显式强制转换，就像以前一样。 所以与其这样做

((Activity1) mainActivity).hideDialog();

我应该做的

((Activity2) mainActivity).hideDialog();

注意:但是这个错误在android 8.0上没有发生，我还不确定为什么。

***希望能有所帮助。

我有这个分割错误错误，因为内存问题。 我的结构体有很多变量和数组，数组的大小是1024。

将大小减小到512，错误就消失了。

附注:这是一种变通方法，而不是解决方案。 有必要找到结构的大小和动态内存分配 是更好的选择。

在从android迁移后，我刚刚遇到了这个问题。支持androidx。

问题在于renderscript。

解决方案: 我从我的建筑中移除。Gradle这两句话:

renderscriptTargetApi 21
renderscriptSupportModeEnabled true

在项目建设失败后，因为未解决的引用:

import androidx.renderscript.Allocation;
import androidx.renderscript.Element;
import androidx.renderscript.RenderScript;
import androidx.renderscript.ScriptIntrinsicBlur;

所以我把它们改成:

import android.renderscript.Allocation;
import android.renderscript.Element;
import android.renderscript.RenderScript;
import android.renderscript.ScriptIntrinsicBlur;

从那以后，所有的问题都解决了。

当我在onDraw()函数中使用ViewTreeObserver时，我得到了这个错误。

@Override
protected void onDraw(Canvas canvas) {
    // super.onDraw(canvas);
    ViewTreeObserver vto = mTextView.getViewTreeObserver();
    vto.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
        @Override
        public void onGlobalLayout() {
            // some animation        
        }
    });
 }

在我的情况下(我使用Xamarin表单)这个错误是由于绑定错误抛出的-例如:

<Label Grid.Column="4" Grid.Row="1" VerticalTextAlignment="Start" HorizontalTextAlignment="Center"  VerticalOptions="Start" HorizontalOptions="Start" FontSize="10" TextColor="Pink" Text="{Binding }"></Label>

基本上我错误地删除了视图模型属性。对于Xamarin开发人员，如果您有同样的问题，请检查您的绑定……

我有这个问题与包，被添加到我的应用程序(FancyShowCaseView)，并导致这个问题在前棒棒糖。这个包是用kotlin写的，我的主要代码是用java写的。所以现在我在pre-lolipop中检查版本，不让它的类被执行。暂时解决了问题。 如果你和我有类似的问题，看看这个

当我使用Android的PDF api创建PDF时，我遇到了这个问题，我在关闭PDF页面后不小心使用了canvas.save()和canvas.restore()。

如果您在项目中添加了一些本地C代码，这个答案可能会很有帮助。

我在Android项目中添加了一些原生C代码。

现在我试图访问的代码是返回本机字符串给我，在处理字符串之前，我已经将其默认值设置为nullptr。现在在Java代码中检索它的值时遇到了这个问题。

因为我们的原生C代码是从Java目录中出来的，所以没有确切的代码行线索，这是造成问题的原因。因此，我建议您检查您的.cpp文件，并尝试找到任何线索。

将这两行添加到构建中。android部分的Gradle:

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}

对我来说，在Android Studio 4.1，什么是好的ole文件>无效缓存和重新启动

之后就没有致命信号了。我相信肯定和侧写器有关，但也不能确定。我只知道重新启动AS会停止模拟器上的崩溃。

在我的情况下，当使用android的PdfDocument API时，行your_pdf_doc_object.finishPage(your_page)应该在画布抽屉的末尾，否则可能会创建内存异常或内存泄漏。

我为此挣扎了几个小时，最终进入了我正在调试的应用程序的存储细节，并做了“清除数据”。后来运行得很好。在我的情况下，这是一些奇怪的谷歌服务gms漏洞。

我在Android Studio中尝试“应用更改并重新启动活动”时遇到了这个问题，从那时起应用程序就无法启动。原因是我尝试了这个可能在片段内，但我不得不重新启动我的手机，我用来测试我的应用程序，然后问题就消失了。

我在使用Flutter 2.8.1时遇到了这个问题。

我搜索了很多，但没有什么帮助(禁用我正在使用的外部包，调试，使缓存无效，颤振清理，重新启动模拟器，等等)。

事实证明，这与我在CustomPainter类中所做的工作有关。即使画一个简单的矩形也可能导致这种崩溃。

我切换到beta通道(Flutter 2.9.0-0.1.pre)，问题完全消失了。

当我使用ics-openvpn时，发生了这个错误

A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdead0000 in tid 3548

简单地将“x86”添加到“abiFilters”，如下所示

ndk {
   abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"
}

我在Android Studio上的Java代码上出现了这个错误

我研究了数百万页，包括这一页中所有先前的答案。但我没有找到任何有用的答案。

最后我检查了所有可能产生误差的位置。

这是我修改前的代码

surfaceView.draw(r1, r2, r3, r4, r5, r8);

这是我的代码，经过修正，错误消失了。

synchronized (this) {
surfaceView.draw(r1, r2, r3, r4, r5, r8);

}

我有SharedPreferences引起的这个问题，我有两个保存数据的方法。一个使用editor.apply()，另一个使用editor.commit()。我把它们都改成了editor.commit()，一切都很顺利。 方法1

    private void saveId(int id) {
    SharedPreferences preferences = getSharedPreferences("saved_id", Context.MODE_PRIVATE);
    SharedPreferences.Editor editor = preferences.edit();
    editor.putInt("bId", id);
    editor.commit();
}    

方法2

private void saveUserData(String saveName, String data){
    SharedPreferences preferences = getPreferences(MODE_PRIVATE);
    SharedPreferences.Editor editor = preferences.edit();
    editor.putString(saveName,data);
    editor.commit();
}

对于在Xamarin项目中遇到此类错误的任何人，都有必要尝试确定导致该问题所需的交互(例如点击按钮)，并放置一个try-catch块以从中获取托管异常。在我的案例中，Android致命信号11 (SIGSEGV)错误最初是由一个托管的c#异常引起的，这个异常可以很容易地修复。我不明白为什么Xamarin不向调试输出报告托管异常。

在我的情况下，我必须找到内存泄漏在我的片段!

我是android studio的用户剖析器，我最终从数据库中获取数据。

注意内存泄漏!

快乐编码:)