androidsignal11

1. 遇到Fatal signal 11 求解答

项目问题，目前已解决；在此记录。

前些天在调试Camera模块；发现相同的代码在厂家提供的环境里边编译、就是ok的，在我们的源码树中编译，将HAL库推进去后、就会signal 11退出。

一、现象

[plain] view plain在CODE上查看代码片派生到我的代码片
F/libc ( 4250): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 4358 (CameraPreviewTh)
I/DEBUG ( 2366): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 2366): Build fingerprint: 'TV/tclm6/tclm6:4.2.1/V8-AML7601-LF1R001/20130523:eng/test-keys'
I/DEBUG ( 2366): Revision: '32'
I/DEBUG ( 2366): pid: 4250, tid: 4358, name: CameraPreviewTh >>> /system/bin/mediaserver <<<
I/DEBUG ( 2366): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG ( 2366): r0 00000000 r1 00000500 r2 45498500 r3 0000001e
I/DEBUG ( 2366): r4 00000280 r5 00000000 r6 00000780 r7 00000000
I/DEBUG ( 2366): r8 00000500 r9 00000780 sl 00000f00 fp 45498f00
I/DEBUG ( 2366): ip 00000280 sp 46054d80 lr 4410816f pc 44108214 cpsr 80030030
I/DEBUG ( 2366): d0 696765623e3e3e31 d1 3e3e3e2d2d2d2d2d
I/DEBUG ( 2366): d2 3234767975793e3e d3 32766e5f6f745f32
I/DEBUG ( 2366): d4 54535f5745495645 d5 4552503e2d455441
I/DEBUG ( 2366): d6 4154535f57454956 d7 0000823549742400
I/DEBUG ( 2366): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 2366): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 2366): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 2366): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 2366): d16 0000000000000000 d17 0000000000000000
I/DEBUG ( 2366): d18 4000000000000000 d19 bf66c168e3a87def
I/DEBUG ( 2366): d20 3fc555533bceb625 d21 3e66376972bea4d0
I/DEBUG ( 2366): d22 3fb0271122ac41c2 d23 bf8388915620e116
I/DEBUG ( 2366): d24 3ff0271122ac41c2 d25 0000000000000000
I/DEBUG ( 2366): d26 0000000000000000 d27 0000000000000000
I/DEBUG ( 2366): d28 0000000000000000 d29 0000000000000000
I/DEBUG ( 2366): d30 0000000000000000 d31 0000000000000000
I/DEBUG ( 2366): scr 60000010
I/DEBUG ( 2366):
I/DEBUG ( 2366): backtrace:
I/DEBUG ( 2366): #00 pc 0002e214 /system/lib/hw/camera.meson6.so (yuyv422_to_nv21(unsigned char*, unsigned char*, int, int)+195)
I/DEBUG ( 2366): #01 pc 0002d05b /system/lib/hw/camera.meson6.so (android::V4LCameraAdapter::previewThread()+490)
I/DEBUG ( 2366): #02 pc 0002d145 /system/lib/hw/camera.meson6.so
I/DEBUG ( 2366): #03 pc 00011253 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+94)
I/DEBUG ( 2366): #04 pc 00010dcd /system/lib/libutils.so
I/DEBUG ( 2366): #05 pc 0000e478 /system/lib/libc.so (__thread_entry+72)
I/DEBUG ( 2366): #06 pc 0000db64 /system/lib/libc.so (pthread_create+160)
I/DEBUG ( 2366):
I/DEBUG ( 2366): stack:
I/DEBUG ( 2366): 46054d40 401da160 /system/lib/libc.so
I/DEBUG ( 2366): 46054d44 401b3a6d /system/lib/libc.so (vfprintf+44)
I/DEBUG ( 2366): 46054d48 000001e0
I/DEBUG ( 2366): 46054d4c 00000280
I/DEBUG ( 2366): 46054d50 4411bce1 /system/lib/hw/camera.meson6.so
I/DEBUG ( 2366): 46054d54 45498500 /dev/video0
I/DEBUG ( 2366): 46054d58 00000003
I/DEBUG ( 2366): 46054d5c 401b167d /system/lib/libc.so (printf+24)
I/DEBUG ( 2366): 46054d60 4411d5fa /system/lib/hw/camera.meson6.so
I/DEBUG ( 2366): 46054d64 46054d74
I/DEBUG ( 2366): 46054d68 00000280
I/DEBUG ( 2366): 46054d6c 4410816f /system/lib/hw/camera.meson6.so (yuyv422_to_nv21(unsigned char*, unsigned char*, int, int)+30)
I/DEBUG ( 2366): 46054d70 4411d5fa /system/lib/hw/camera.meson6.so
I/DEBUG ( 2366): 46054d74 00000000
I/DEBUG ( 2366): 46054d78 df0027ad
I/DEBUG ( 2366): 46054d7c 00000000
I/DEBUG ( 2366): #00 46054d80 00000280
I/DEBUG ( 2366): 46054d84 45498000 /dev/video0
I/DEBUG ( 2366): 46054d88 45498500 /dev/video0
I/DEBUG ( 2366): 46054d8c 45498a00 /dev/video0
I/DEBUG ( 2366): 46054d90 00000780
I/DEBUG ( 2366): 46054d94 0004b000
I/DEBUG ( 2366): 46054d98 0004b280
I/DEBUG ( 2366): 46054d9c 0004b001
I/DEBUG ( 2366): 46054da0 0004b281
I/DEBUG ( 2366): 46054da4 45498000 /dev/video0
I/DEBUG ( 2366): 46054da8 45498500 /dev/video0
I/DEBUG ( 2366): 46054dac 45498a00 /dev/video0
I/DEBUG ( 2366): 46054db0 45498f00 /dev/video0
I/DEBUG ( 2366): 46054db4 45498001 /dev/video0
I/DEBUG ( 2366): 46054db8 45498a01 /dev/video0
I/DEBUG ( 2366): 46054dbc 45498003 /dev/video0
I/DEBUG ( 2366): ........ ........
I/DEBUG ( 2366): #01 46054e08 00000000
I/DEBUG ( 2366): 46054e0c 00000000
I/DEBUG ( 2366): 46054e10 00000000
I/DEBUG ( 2366): 46054e14 00000000
I/DEBUG ( 2366): 46054e18 00000000
I/DEBUG ( 2366): 46054e1c 00000000
I/DEBUG ( 2366): 46054e20 00000000
I/DEBUG ( 2366): 46054e24 00000000
I/DEBUG ( 2366): 46054e28 00000280
I/DEBUG ( 2366): 46054e2c 000001e0
I/DEBUG ( 2366): 46054e30 00000000
I/DEBUG ( 2366): 46054e34 00000000
I/DEBUG ( 2366): 46054e38 00000000
I/DEBUG ( 2366): 46054e3c 00000000
I/DEBUG ( 2366): 46054e40 00000000
I/DEBUG ( 2366): 46054e44 00000000
I/DEBUG ( 2366): ........ ........
I/DEBUG ( 2366): #02 46054e98 44001498
I/DEBUG ( 2366): 46054e9c 40226255 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+96)
I/DEBUG ( 2366):
I/DEBUG ( 2366): memory near r2:
I/DEBUG ( 2366): 454984e0 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 454984f0 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498500 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498510 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498520 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498530 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498540 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498550 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498560 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498570 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498580 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498590 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 454985a0 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 454985b0 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 454985c0 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 454985d0 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366):
I/DEBUG ( 2366): memory near fp:
I/DEBUG ( 2366): 45498ee0 ffffffff ffffffff ffffffff ffffffffI/DEBUG ( 2366): 45498ef0 ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 2366): 45498f00 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f10 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f20 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f30 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f40 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f50 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f60 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f70 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f80 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498f90 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498fa0 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498fb0 ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 2366): 45498fc0 ffffffff ffffffff ffffffff..
二、解决

1.分析其中的重要信息

[plain] view plain在CODE上查看代码片派生到我的代码片
I/DEBUG ( 2366): #00 pc 0002e180 /system/lib/hw/camera.meson6.so (yuyv422_to_nv21(unsigned char*, unsigned char*, int, int)+157)
I/DEBUG ( 2366): #01 pc 0002d00b /system/lib/hw/camera.meson6.so (android::V4LCameraAdapter::previewThread()+458)
I/DEBUG ( 2366): #02 pc 0002d0dd /system/lib/hw/camera.meson6.so
I/DEBUG ( 2366): #03 pc 00011253 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+94)
I/DEBUG ( 2366): #04 pc 00010dcd /system/lib/libutils.so
I/DEBUG ( 2366): #05 pc 0000e478 /system/lib/libc.so (__thread_entry+72)
I/DEBUG ( 2366): #06 pc 0000db64 /system/lib/libc.so (pthread_create+160)
2.代码跟踪

操作：
out/target/proct/tclm6/obj/SHARED_LIBRARIES/camera.meson6_intermediates/LINKED
arm-none-linux-gnueabi-addr2line 0002e180 -e camera.meson6.so
结果：
hardware/amlogic/camera/utils/util.cpp:157
////(*ptrdesty1++) = (*ptrsrcy1);在yuyv422_to_nv21(unsigned char*, unsigned char*, int, int）函数中

操作：
arm-none-linux-gnueabi-addr2line 0002d00b -e camera.meson6.so
结果：
hardware/amlogic/camera/V4LCameraAdapter/V4LCameraAdapter.cpp:1571
//// yuyv422_to_nv21(src,dest,width,height);

操作：
arm-none-linux-gnueabi-addr2line 0002d0dd -e camera.meson6.so
结果：
hardware/amlogic/camera/V4LCameraAdapter/V4LCameraAdapter.cpp:303
////writefile((char*)SYSFILE_CAMERA_SET_PARA, (char*)"1");
3.分析

从上边结果来看，在hardware/amlogic/camera/V4LCameraAdapter/V4LCameraAdapter.cpp:1571处调用yuyv422_to_nv21(src,dest,width,height)挂掉的可能性比较打；于是加如下log：

[plain] view plain在CODE上查看代码片派生到我的代码片
D/V4LCameraAdapter( 2371): TK----------->>>>>src is 0x45d0f000
D/V4LCameraAdapter( 2371): TK---------->>>>>>dest is 0x0
D/V4LCameraAdapter( 2371): TK------------>>>>>width is 640
D/V4LCameraAdapter( 2371): TK--------->>>>>height is 480
不难发现，上边dest指针为NULL、导致的signal 11。

4.解决

通过对比编译环境发现，在dest赋值处；用到的头文件位置不同，导致结果差异。通过重新设置头文件路径，问题解决。

三、思考

目前掌握的结局signal 11故障的方法是使用交叉编译工具链给我们提供的arm-none-linux-gnueabi-addr2line工具，通过地址定位源文件中出错的函数或具体行数。

四、补充：Fatal signal 8 (SIGFPE)

最近在帮助同事看一个打印堆栈问题时发现，程序并没有被kill掉

[plain] view plain在CODE上查看代码片派生到我的代码片
F/libc ( 3254): Fatal signal 8 (SIGFPE) at 0x00000cb6 (code=0), thread 3254 (TVMSFserver)
I/DEBUG ( 2455): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 2455): Build fingerprint: 'TV/tclm6/tclm6:4.2.2/V8-AML7602-LF1V002/20140520:eng/test-keys'
I/DEBUG ( 2455): Revision: '32'
I/DEBUG ( 2455): pid: 3254, tid: 3254, name: TVMSFserver >>> TVMSFserver <<<
I/DEBUG ( 2455): signal 8 (SIGFPE), code -6 (?), fault addr 00000cb6
D/atv_hd ( 2439): ATVTunerSetStd, tuner std = 0x40000e0(V4L2_COLOR_STD_PAL, V4L2_STD_PAL_DK).
I/DEBUG ( 2455): r0 00000000 r1 00000008 r2 0000270f r3 00000000
I/DEBUG ( 2455): r4 00000000 r5 ffffffff r6 00000000 r7 00000025
I/DEBUG ( 2455): r8 00000001 r9 00000000 sl 4012e228 fp bed8ca2c
I/DEBUG ( 2455): ip fffdc390 sp bed8c660 lr 4011e010 pc 400fc27c cpsr 200a0010
I/DEBUG ( 2455): d0 6168772d2d2d2d2d d1 5654582d2d2d2d2d
I/DEBUG ( 2455): d2 6b6361626c6c6163 d3 2d2d2d2d7070632e
I/DEBUG ( 2455): d4 6c6c61635654582d d5 45533a3a6b636162
I/DEBUG ( 2455): d6 4c41435f48435241 d7 2d2d2d4b4341424c
I/DEBUG ( 2455): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 2455): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 2455): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 2455): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 2455): d16 41d4e400c2003127 d17 3f50624dd2f1a9fc
I/DEBUG ( 2455): d18 41cc382ea1800000 d19 0000000000000000
I/DEBUG ( 2455): d20 0000000000000000 d21 0000000000000000
I/DEBUG ( 2455): d22 0000000000000000 d23 0000000000000000
I/DEBUG ( 2455): d24 0000000000000000 d25 0000000000000000
I/DEBUG ( 2455): d26 0000000000000000 d27 0000000000000000
I/DEBUG ( 2455): d28 0000000000000000 d29 0000000000000000
I/DEBUG ( 2455): d30 0000000000000000 d31 0000000000000000
I/DEBUG ( 2455): scr 00000010
I/DEBUG ( 2455):
I/DEBUG ( 2455): backtrace:
I/DEBUG ( 2455): #00 pc 0001827c /system/lib/libc.so (kill+12)
I/DEBUG ( 2455): #01 pc 0003a00c /system/lib/libc.so (__aeabi_idiv0+8)
I/DEBUG ( 2455):
I/DEBUG ( 2455): stack:
I/DEBUG ( 2455): bed8c620 00000008
I/DEBUG ( 2455): bed8c624 00000000
I/DEBUG ( 2455): bed8c628 00000000
I/DEBUG ( 2455): bed8c62c 00000000
I/DEBUG ( 2455): bed8c630 00000000
I/DEBUG ( 2455): bed8c634 41010001 /system/lib/libamplayer.so (ff_ps_init+1361)
I/DEBUG ( 2455): bed8c638 00000000
I/DEBUG ( 2455): bed8c63c 00000030
I/DEBUG ( 2455): bed8c640 ffffffe0
I/DEBUG ( 2455): bed8c644 00000000
I/DEBUG ( 2455): bed8c648 00000000
I/DEBUG ( 2455): bed8c64c 00000000
I/DEBUG ( 2455): bed8c650 00000000
I/DEBUG ( 2455): bed8c654 00000000
I/DEBUG ( 2455): bed8c658 df0027ad
I/DEBUG ( 2455): bed8c65c 00000000
I/DEBUG ( 2455): #00 bed8c660 00000000
I/DEBUG ( 2455): ........ ........
I/DEBUG ( 2455): #01 bed8c660 00000000
I/DEBUG ( 2455): bed8c664 ffffffff
I/DEBUG ( 2455): bed8c668 00000000
I/DEBUG ( 2455): bed8c66c bed8c6a0 [stack]
I/DEBUG ( 2455): bed8c670 fffdc390
I/DEBUG ( 2455): bed8c674 4011e010 /system/lib/libc.so (__aeabi_idiv0+12)
I/DEBUG ( 2455): bed8c678 00000000
I/DEBUG ( 2455): bed8c67c 4038223d /data/test/libTVMSFService.so (android::postEventsFromhal(int, android::Parcel const*)+236)
I/DEBUG ( 2455): bed8c680 00000002
I/DEBUG ( 2455): bed8c684 00000002
I/DEBUG ( 2455): bed8c688 41bd2c28
I/DEBUG ( 2455): bed8c68c 00000063
I/DEBUG ( 2455): bed8c690 000c2e2a
I/DEBUG ( 2455): bed8c694 00000003
I/DEBUG ( 2455): bed8c698 00000004
I/DEBUG ( 2455): bed8c69c 418fbb01 /data/test/libdtvapi_dtv.so (std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::xsputn(char const*, int)+8)
通过地址定位：
arm-none-linux-gnueabi-addr2line 0001827c -e libc.so
结果：

bionic/libc/arch-arm/bionic/kill.S:46

[plain] view plain在CODE上查看代码片派生到我的代码片
ENTRY(kill)
stmfd sp!, {r4-r7, ip, lr}
ldr r7, =__NR_kill
swi #0
ldmfd sp!, {r4-r7, ip, lr} //46行，恢复现场
movs r0, r0
bxpl lr
b __set_syscall_errno
END(kill)
后发现signal 8问题一般是由于除数为0导致，后问题解决；通过该问题分析：可能是因为signal 8后系统需要kill该进程、但没有kill成功。

2. 求助， android的logcat中signal 11 (SIGSEGV)是种什么类型的错误，能从表象上看出什么问题吗

你可以在工程里面搜索这个关键字。
我这边搜索了一下，SIGSEGV的定义如下：
#define SIGSEGV 11
只是一个普通的定义。
使用起来如下：
const char *get_signame(int sig)
{
switch(sig) {
...
case SIGSEGV: return "SIGSEGV";
...
}
不知道你说的是不是这个了，但是这边使用的时候是按照int来使用的。其实主要是要知道SIGSEGV的含义，在判断singal的时候可以使用。

3. 如何分析Android的Log

首先，让我们看一看AndroidLog的格式。下面这段log是以所谓的long格式打印出来的。从前面Logcat的介绍中可以知道，long格式会把时间，标签等作为单独的一行显示。

这个log就不那么容易懂了，但是还是能从中看出很多信息，让我们一起来学习如何分析这种log。首先看下面这行：

pid: 2102, tid: 2102,name: testapp >>>./testapp <<<

从这一行我们可以知道crash进程的pid和tid，前文我们已经提到过，Android调用gettid函数得到的实际是进程Id号，所以这里的pid和tid相同。知道进程号后我们可以往前翻翻log，看看该进程最后一次打印的log是什么，这样能缩小一点范围。

接下来内容是进程名和启动参数。再接下来的一行比较重要了，它告诉了我们从系统角度看，出错的原因：

signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000

signal11是Linux定义的信号之一，含义是Invalidmemory reference，无效的内存引用。加上后面的“faultaddr
00000000”我们基本可以判定这是一个空指针导致的crash。当然这是笔者为了讲解而特地制造的一个Crash的例子，比较容易判断，大部分实际的例子可能就没有那么容易了。

再接下来的log打印出了cpu的所有寄存器的信息和堆栈的信息，这里面最重要的是从堆栈中得到的backtrace信息：

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

因为实际的运行系统里没有符号信息，所以打印出的log里看不出文件名和行数。这就需要我们借助编译时留下的符号信息表来翻译了。Android提供了一个工具可以来做这种翻译工作：arm-eabi-addr2line，位于prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目录下。用法很简单：

#./arm-eabi-addr2line -f
-eout/target/proct/hammerhead/symbols/system/bin/testapp0x0000045e

参数-f表示打印函数名；参数-e表示带符号表的模块路径；最后是要转换的地址。这条命令在笔者的编译环境中得到的结果是：

memcpy
/home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108

剩余三个地址翻译如下：

main
/home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38

out_vformat
/home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361

_start libgcc2.c:0

利用这些信息我们很快就能定位问题了。不过这样手动一条一条的翻译比较麻烦，笔者使用的是从网上找到的一个脚本，可以一次翻译所有的行，有需要的读者可以在网上找一找。

4. 这个C程序为什么会出现signal11

signal11 -- 信号11 （表示有错）
c 语言要先写声明，后写语句。
m 数组用动态分配方法 获得 存储空间。
循环到字符串长度，不要用 100。
#include<stdio.h>
int main()
{
int a=0,b=0,c=0;
char (*m)[100]; //声明指针
scanf("%d",&a);
m = (char (*)[100]) malloc(a*sizeof(char)); //动态分配
for(b=0;b<=a;b++)
{
gets(m[b]);
for(c=0;c<strlen(m[b]);c++) //循环控制
{
if(m[b][c]>='A'&& m[b][c]<='Z')
m[b][c]+=32;
else if(m[b][c]>='a'&& m[b][c]<='z')
m[b][c]-=32;
}
}
for(b=0;b<=a;b++)
{
puts(m[b]);
}
return 0;
}

5. android Fatal signal 11 (SIGSEGV) at 0x00000008 (code=1)

dll 或 so崩了，多数是非法访问内存引起的，如访问越界，访问非法内存

6. Android运行时随机出现Fatal signal 11 (SIGSEGV) at 0xa7543c80 (code=2), thread 3459 (Thread-204)

很多错误都会导致这个问题， 基本上只要程序crash了， 就会有个fatal什么的， 建议从这个报错开始往上跟踪log，看有没有什么其他error信息

7. android webview fatal signal 11 怎么解决

超出了你的显示器支持的最大分辨率，把极品的分辨率调低点就没事了。
20寸的显示器，最佳分辨率就是1600X900。

8. Android、Java开发相关：A/libc(28088): Fatal signal 11 (SIGSEGV) at 0x616f708c (code=1),

这个错误一般是出现了内存泄露问题，可以检查一下是否出现了野指针，或者某些线程或者实例是否及时关闭，谢谢

9. 如何定位Android NDK开发中遇到的错误

利用Android NDK开发本地应用时，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“Android NDK崩溃”，可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误，但大都晦涩难懂。下面以一个实际的例子来说明，如何通过两种不同的方法，来定位错误的函数名和代码行。
首先，来看看我们在hello-jni程序的代码中做了什么（有关如何创建或导入工程，此处略），下面代码中：在JNI_OnLoad()的函数中，即so加载时，调用willCrash()函数，而在willCrash()函数中， std::string的这种赋值方法会产生一个空指针错误。这样，在hello-jni程序加载时就会闪退。我们记一下这两个行数：在61行调用了willCrash()函数；在69行发生了崩溃。
第一种方法：ndk-stack
这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk –stack命令也有两种方式
第二种方法：使用addr2line和objmp命令
这个方法适用于那些不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但可以稍稍满足一下程序员的好奇心。
先简单说一下这两个命令，在绝大部分的Linux发行版本中都能找到他们，如果你的操作系统是Linux，而你测试手机使用的是Intel x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。
参考更多请关注扣丁学堂IT教育。。。。。。。。。。。。。。。。。。。。。

10. 如何定位android ndk开发中遇到的错误

NDK错误发生时，我们能拿到什么信息？

利用Android
NDK开发本地应用的时候，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“Android
NDK崩溃”，可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误，但大都晦涩难懂。下面以一个实际的例子来说明，首先生成一个错误，然后演示如何通过两种不同的方法，来定位错误的函数名和代码行。

首先，看我们在hello-jni程序的代码中做了什么（有关如何创建或导入工程，此处略），看下图：在JNI_OnLoad()的函数中，即so加载时，调用willCrash()函数，而在willCrash()函数中， std::string的这种赋值方法会产生一个空指针错误。这样，在hello-jni程序加载时就会闪退。我们记一下这两个行数：在61行调用了willCrash()函数；在69行发生了崩溃。

下面来看看发生崩溃（闪退）时系统打印的logcat日志：

[plain] view
plain

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

Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'

pid: 32607, tid: 32607, name: xample.hellojni >>> com.example.hellojni <<<

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000

r0 00000000 r1 beb123a8 r2 80808080 r3 00000000

r4 5d635f68 r5 5cdc3198 r6 41efcb18 r7 5d62df44

r8 4121b0c0 r9 00000001 sl 00000000 fp beb1238c

ip 5d635f7c sp beb12380 lr 5d62ddec pc 400e7438 cpsr 60000010backtrace:

#00 pc 00023438 /system/lib/libc.so

#01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so

#02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so

#03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so

#04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so

#05 pc 000505b9 /system/lib/libdvm.so

#06 pc 00068005 /system/lib/libdvm.so

#07 pc 000278a0 /system/lib/libdvm.so

#08 pc 0002b7fc /system/lib/libdvm.so

#09 pc 00060fe1 /system/lib/libdvm.so

#10 pc 0006100b /system/lib/libdvm.so

#11 pc 0006c6eb /system/lib/libdvm.so

#12 pc 00067a1f /system/lib/libdvm.so

#13 pc 000278a0 /system/lib/libdvm.so

#14 pc 0002b7fc /system/lib/libdvm.so

#15 pc 00061307 /system/lib/libdvm.so

#16 pc 0006912d /system/lib/libdvm.so

#17 pc 000278a0 /system/lib/libdvm.so

#18 pc 0002b7fc /system/lib/libdvm.so

#19 pc 00060fe1 /system/lib/libdvm.so

#20 pc 00049ff9 /system/lib/libdvm.so

#21 pc 0004d419 /system/lib/libandroid_runtime.so

#22 pc 0004e1bd /system/lib/libandroid_runtime.so

#23 pc 00001d37 /system/bin/app_process

#24 pc 0001bd98 /system/lib/libc.so

#25 pc 00001904 /system/bin/app_processstack:

beb12340 012153f8

beb12344 00054290

beb12348 00000035

beb1234c beb123c0 [stack]……

如果看过logcat打印的NDK错误时的日志就会知道，省略了后面很多的内容，很多人看到这么多密密麻麻的日志就已经头晕脑胀了，即使是很多资深的Android开发者，在面对NDK日志时也大都默默的选择了无视。