Fatal signal 11 (SIGSEGV) 错误捕获并抛出给JAVA - 简书
Fatal signal 11 (SIGSEGV) 错误捕获并抛出给JAVA
公司从人人网接收了经纬名片通，开始进行后续开发。该项目安卓的名片本地识别模块是调JNI的，最底层识别图片的部分暂时没有源代码。糟糕的是，该模块在部分机型上出现闪退，并报错：Fatal signal 11 (SIGSEGV) at .... (code=1)
谷歌翻了十几页，都是讲怎么定位错误，怎么修改错误。可是底层的代码我没有啊，就算定位了也改不了。而且项目等着上线，就算后续要到源码也来不及了。所以，我要做的只是让C把错误抛给Java，别让程序闪退即可。
这里，我们需要用到C的两组库函数：signal、setjmp/longjmp
信号是程序处理中的异常情况，信号产生时，系统会进行一些默认的操作。通过signal函数，可以把这些默认操作更改为自己定义的操作。signal函数的头文件：
#include &iostream&
#include &csignal&
"message": "sucess",
"status": 0
signal函数定义：
static __inline__ __sighandler_t signal(int s, __sighandler_t f)
signal函数调用：
void handler(int sig){...}
signal(SIGSEGV, handler);
其中，SIGSEGV就是错误里面提示的那个信号，在signal.h的头文件里，它被定义为11。是不是有豁然开朗的感觉？^_^我们需要在可能出错的函数里写上：signal(SIGSEGV, handler)一旦系统接收到SIGSEGV，就会自动执行handler函数。
handler函数是自定义的，它的参数就是signal函数的一个参数。我们来完善一下它。
void handler(int sig) {
//解除绑定到信号上的方法
signal(sig, SIG_DFL);
throwJNIException(penv);
JNIEXPORT void throwJNIException(JNIEnv* pEnv) {
//注意JNIException的路径
jclass lClass = pEnv-&FindClass("com/jingwei/ocrs/JNIException");
if (lClass != NULL) {
pEnv-&ThrowNew(lClass, "Throw JNIException");
//如果我们长时间不再需要引用这个异常类时，可以使用DeleteLocalRef()来解除它。
pEnv-&DeleteLocalRef(lClass);
handler函数的第一行，是将相应信号的操作重新改为系统默认的操作。SIG_DFL代表执行系统默认操作，类似地，SIG_ING 代表忽略信号。penv是出错的方法的环境，在文末总结的时候可以看到。throwJNIException函数是把错误抛给JAVA，本例中需要新建一个JAVA的Exception类JNIException，这里不再贴代码。
C语言不像JAVA，JAVA底层抛出错误后就可以不管了，而C语言需要函数正常返回。这时候我们就需要setjmp/longjmp函数。这两个函数有点像goto一样，可以互相跳转。setjmp/longjmp函数的头文件：
#include &setjmp.h&
setjmp/longjmp函数定义：
setjmp(jmp_buf);
longjmp(jmp_buf, int);
来看一个从维基百科抄来的经典例子：
#include &stdio.h&
#include &setjmp.h&
static jmp_
void second(void) {
printf("second\n"); // 打印
longjmp(buf,1); // 跳回setjmp的调用处 - 使得setjmp返回值为1
void first(void) {
printf("first\n"); // 不可能执行到此行
int main() {
if (!setjmp(buf)) {
first(); // 进入此行前，setjmp返回0
// 当longjmp跳转回，setjmp返回1，因此进入此行
printf("main\n"); // 打印
打印结果：
main函数先执行到if语句，setjmp将程序的调用环境存储在缓冲区buf中。setjmp如果是首次调用会返回0，于是程序进入first函数。从first函数进入second函数并遇到longjmp后，程序会返回main函数的if语句。此时，setjmp的返回值会变成longjmp的第二个参数，于是打印"main"后结束。
所以最终，程序看起来应该是这个样子：
#include &iostream&
#include &csignal&
#include &setjmp.h&
static jmp_
JNIEnv* penv = NULL;
void handler(int sig) {
//解除绑定到信号上的方法
signal(sig, SIG_DFL);
throwJNIException(penv);
longjmp (jumpflg, 1);
JNIEXPORT void throwJNIException(JNIEnv* pEnv) {
//注意JNIException的路径
jclass lClass = pEnv-&FindClass("com/jingwei/ocrs/JNIException");
if (lClass != NULL) {
pEnv-&ThrowNew(lClass, "Throw JNIException");
//如果我们长时间不再需要引用这个异常类时，可以使用DeleteLocalRef()来解除它。
pEnv-&DeleteLocalRef(lClass);
JNIEXPORT jint JNICALL Java_com_jingwei_ocrs_OCRHandler(JNIEnv* env, jobject thiz) {
signal(SIGSEGV, handler);
if (!setjmp(jumpflg)) {
//可能有错误的语句写在这里
至此，外层JAVA即可捕捉JNIException。不过调试中发现，部分机型会抛出StackOverflowError，具体原因不明，所以外层不得不在捕捉JNIException的同时，也捕捉StackOverflowError。求大神相助,关于 Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 1531
这个问题在网上查找了较多的资料
首先这是一个底层的错误
有人说这个是因为多线程互斥的问题,要加synchronized
有人说是因为jni问题
不过都没有解决我的问题,我发觉很多人都提到个问题
就是在2.x的系统就没有问题,放到4.x的系统就有问题了
我的也是这样的,有哪位大牛知道
02:09&&&[]
这个问题在网上查找了较多的资料
首先这是一个底层的错误
有人说这个是因为多线程互斥的问题,要加synchronized
有人说是因为jni问题
不过都没有解决我的问题,我发觉很多人都提到个问题
就是在2.x的系统就没有问题,放到4.x的系统就有问题了
我的也是这样的,有哪位大牛知道
21:45&&&[]
这个问题在网上查找了较多的资料
首先这是一个底层的错误
有人说这个是因为多线程互斥的问题,要加synchronized
有人说是因为jni问题
不过都没有解决我的问题,我发觉很多人都提到个问题
就是在2.x的系统就没有问题,放到4.x的系统就有问题了
我的也是这样的,有哪位大牛知道
20:53&&&[]
04-10&10:34:19.297:&A/libc(1564):&Fatal&signal&11&(SIGSEGV)&at&0x7b386140&(code=1),&thread
10:54&&&[]
这是log提示
这是控制台的提示
[2013-11-23&19:58:02&-&SDK&Manager]&[SDK&Manager]&十一月&23,&:02&下午
-15:42&&&[]
使用Fresco 0.9.0版本加载通过拍照得到的图片的本地的Uri，BUG导致：应用程序崩溃，过一小会儿会自动退出。 并且会报错 Fatal&signal&11&(SIGSEGV)&at&0x&(code=1
17:13&&&[]
02-10&16:49:09.455&980-980/?&I/DEBUG:&signal&11&(SIGSEGV),&code&1&(SEGV_MAPERR),&nbsp
02:15&&&[]
崩溃，不过报错信息变了，“Fatal signal 11 (SIGSEGV) at 0x (code=1)”，在网上查了很多，到处都是引用的下面这篇文章，但是这篇文章根本不能解决我的问题。
& & & & &&nbsp
16:37&&&[]
&signal&11&(SIGSEGV)&at&0xdeadbaad&(code=1),&thread&3661&(ervice.Executor)。这个是由android&linux&内核libc函数抛出的一个
17:18&&&[]
;Fatal&signal&11&(SIGSEGV),&code&2,&fault&addr&0x7f7977cce0&in&tid&2182&(system_server)
23:34&&&[]
threadLoop方法中调用成员变量mWorker的loopOnce方法，但在这个地方报错Fatal&signal&11&(SIGSEGV)。整了几点怎么试都不能解决，有大侠能帮忙诊断下吗，我将无比感激。
#include&&jni.h&gt
13:34&&&[]
;A/libc(1405):&Fatal&signal&11&(SIGSEGV)&at&0xdeadbaad&(code=1),&thread&1405&(.novonity.uchat) 以上
21:01&&&[]56542人阅读
移动操作系统之Android（106）
项目问题，目前已解决；在此记录。
前些天在调试Camera模块；发现相同的代码在厂家提供的环境里边编译、就是ok的，在我们的源码树中编译，将HAL库推进去后、就会signal 11退出。
( 4250): Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 4358 (CameraPreviewTh)
( 2366): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
( 2366): Build fingerprint: 'TV/tclm6/tclm6:4.2.1/V8-AML7601-LF1R001/:eng/test-keys'
( 2366): Revision: '32'
( 2366): pid: 4250, tid: 4358, name: CameraPreviewTh
&&& /system/bin/mediaserver &&&
( 2366): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr
r3 0000001e
sl 00000f00
fp 45498f00
sp 46054d80
lr 4410816f
3e3e3e2d2d2d2d2d
d19 bf66c168e3a87def
d20 3fc555533bceb625
d21 3ebea4d0
d23 bfe116
( 2366): backtrace:
/system/lib/hw/camera.meson6.so (yuyv422_to_nv21(unsigned char*, unsigned char*, int, int)+195)
pc 0002d05b
/system/lib/hw/camera.meson6.so (android::V4LCameraAdapter::previewThread()+490)
/system/lib/hw/camera.meson6.so
/system/lib/libutils.so (android::Thread::_threadLoop(void*)+94)
pc 00010dcd
/system/lib/libutils.so
/system/lib/libc.so (__thread_entry+72)
pc 0000db64
/system/lib/libc.so (pthread_create+160)
( 2366): stack:
/system/lib/libc.so
/system/lib/libc.so (vfprintf+44)
/system/lib/hw/camera.meson6.so
/dev/video0
/system/lib/libc.so (printf+24)
/system/lib/hw/camera.meson6.so
/system/lib/hw/camera.meson6.so (yuyv422_to_nv21(unsigned char*, unsigned char*, int, int)+30)
/system/lib/hw/camera.meson6.so
/dev/video0
/dev/video0
/dev/video0
/dev/video0
/dev/video0
/dev/video0
/dev/video0
/dev/video0
/dev/video0
/dev/video0
/system/lib/libutils.so (android::Thread::_threadLoop(void*)+96)
( 2366): memory near r2:
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffff I/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
ffffffff ffffffff ffffffff ffffffffI/DEBUG
( 2366): memory near fp:
45498ee0 ffffffff ffffffff ffffffff ffffffffI/DEBUG
45498ef0 ffffffff ffffffff ffffffff ffffffff
45498f00 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f10 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f20 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f30 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f40 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f50 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f60 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f70 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f80 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498f90 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498fa0 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498fb0 ffffffff ffffffff ffffffff ffffffff I/DEBUG
45498fc0 ffffffff ffffffff ffffffff..
1.分析其中的重要信息
/system/lib/hw/camera.meson6.so (yuyv422_to_nv21(unsigned char*, unsigned char*, int, int)+157)
pc 0002d00b
/system/lib/hw/camera.meson6.so (android::V4LCameraAdapter::previewThread()+458)
pc 0002d0dd
/system/lib/hw/camera.meson6.so
/system/lib/libutils.so (android::Thread::_threadLoop(void*)+94)
pc 00010dcd
/system/lib/libutils.so
/system/lib/libc.so (__thread_entry+72)
pc 0000db64
/system/lib/libc.so (pthread_create+160)
2.代码跟踪
out/target/product/tclm6/obj/SHARED_LIBRARIES/camera.meson6_intermediates/LINKED
arm-none-linux-gnueabi-addr2line
-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&);
& & 从上边结果来看，在hardware/amlogic/camera/V4LCameraAdapter/V4LCameraAdapter.cpp:1571处调用yuyv422_to_nv21(src,dest,width,height)挂掉的可能性比较打；于是加如下log：
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。
& 通过对比编译环境发现，在dest赋值处；用到的头文件位置不同，导致结果差异。通过重新设置头文件路径，问题解决。
& 目前掌握的结局signal 11故障的方法是使用交叉编译工具链给我们提供的arm-none-linux-gnueabi-addr2line工具，通过地址定位源文件中出错的函数或具体行数。
四、补充：Fatal signal 8 (SIGFPE)
& 最近在帮助同事看一个打印堆栈问题时发现，程序并没有被kill掉
( 3254): Fatal signal 8 (SIGFPE) at 0x00000cb6 (code=0), thread 3254 (TVMSFserver)
( 2455): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
( 2455): Build fingerprint: 'TV/tclm6/tclm6:4.2.2/V8-AML7602-LF1V002/:eng/test-keys'
( 2455): Revision: '32'
( 2455): pid: 3254, tid: 3254, name: TVMSFserver
&&& TVMSFserver &&&
( 2455): signal 8 (SIGFPE), code -6 (?), fault addr 00000cb6
( 2439): ATVTunerSetStd, tuner std = 0xL2_COLOR_STD_PAL, V4L2_STD_PAL_DK).
r2 0000270f
r5 ffffffff
fp bed8ca2c
ip fffdc390
sp bed8c660
pc 400fc27c
cpsr 200a0010
2d2d2d2d7070632e
2d2d2d4b4341424c
d16 41d4e400c2003127
d17 3f5a9fc
d18 41cc382ea1800000
( 2455): backtrace:
pc 0001827c
/system/lib/libc.so (kill+12)
pc 0003a00c
/system/lib/libc.so (__aeabi_idiv0+8)
( 2455): stack:
/system/lib/libamplayer.so (ff_ps_init+1361)
/system/lib/libc.so (__aeabi_idiv0+12)
/data/test/libTVMSFService.so (android::postEventsFromhal(int, android::Parcel const*)+236)
/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
ENTRY(kill)
sp!, {r4-r7, ip, lr}
r7, =__NR_kill
sp!, {r4-r7, ip, lr}
//46行，恢复现场
__set_syscall_errno
& 后发现signal 8问题一般是由于除数为0导致，后问题解决；通过该问题分析：可能是因为signal 8后系统需要kill该进程、但没有kill成功。
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：722616次
积分：9443
积分：9443
排名：第1694名
原创：291篇
转载：42篇
(2)(2)(1)(3)(2)(4)(13)(2)(6)(19)(3)(2)(3)(11)(6)(1)(5)(20)(4)(4)(4)(10)(4)(9)(12)(5)(6)(10)(13)(9)(11)(6)(6)(4)(26)(7)(7)(7)(20)(16)(23)(3)(3)}