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日誌時也大都默默的選擇了無視。