Android致命信号11 (SIGSEGV)在0x636f7d89(代码=1)。怎样才能找到它呢?

小开

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

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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。从那以后就没有问题了。

我想我可以给那些处于我这种情况的人的教训是，即使您是一个100% Java应用程序，也要注意崩溃转储中指出的本机库和符号，以寻找线索。谷歌搜索SIGSEGV + lib .so name将比无用的代码=1，等等…接下来，考虑一下您的Java应用程序可以在哪些地方接触本机代码，即使您没有做任何事情。我犯了一个错误，假设这是一个服务+ UI线程问题，其中画布绘制的东西是空的，(最常见的情况下，我谷歌在SIGSEGV)，并忽略了它可能已经完全与我写的代码有关的lib .so在崩溃转储。自然的java。安全性将使用libcrypto中的本机组件。所以为了速度，所以一旦我找到线索，我就谷歌了Android + SIGSEGV + libcrypto。因此，我们找到了文件问题。

小开

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

您的应用程序正在访问其地址空间之外的内存。这很可能是一个无效的指针访问。SIGSEGV =本机代码中的分割错误。因为它不是发生在Java代码中，所以您不会看到包含详细信息的堆栈跟踪。但是，如果在应用程序进程崩溃后稍微查看一下，仍然可以在logcat中看到一些堆栈跟踪信息。它不会告诉您文件中的行号，但会告诉您调用链中使用了哪些目标文件和地址。从这里，您通常可以找出代码的哪个部分有问题。您还可以设置到目标进程的gdb本机连接，并在调试器中捕获它。

小开

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

小开

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

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

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

小开

我在Android 4.4.4上遇到过SIGSEGV (Nexuses，三星) 事实证明，致命错误是在解析null String时使用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()之外的“canvas”时，我遇到了这个错误

    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"

小开

今天我遇到了Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161问题，我挣扎了半天才解决这个问题。

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

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

从这回答:

转到Android工作室设置或首选项(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，错误就消失了。

< p > p。这只是个变通办法，不是解决方案。必须找到结构体大小和动态内存分配

小开

我刚才在从android.support迁移到androidx之后遇到了这个问题。

问题是renderscript。

< p >解决方案: 我从build.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会停止模拟器上的崩溃。 < / p >

小开

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

小开

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

小开

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

小开

我使用颤振2.8.1发布时遇到了这个问题。

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

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

我切换到beta频道(颤振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 < / p >

    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不向调试输出报告托管异常。

小开

在我的情况下，我必须找到memory leak在我的片段!

我用户profiler的android工作室和我发现它最后从数据库的数据。

要注意Memory Leak!

快乐编码:)