signal 11 (SIGSEGV), fault addr 0000015c是什么错误?怎么解决?

xqhrs232 2011-04-21 02:11:43
signal 11 (SIGSEGV), fault addr 0000015c是什么错误?怎么解决?
...全文
12766 27 打赏 收藏 转发到动态 举报
写回复
用AI写文章
27 条回复
切换为时间正序
请发表友善的回复…
发表回复
yan-123456 2012-01-18
  • 打赏
  • 举报
回复
01-18 13:55:08.898: A/libc(31273): Fatal signal 11 (SIGSEGV) at 0x48d20000 (code=2)
01-18 13:55:08.914: I/DEBUG(28313): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-18 13:55:08.914: I/DEBUG(28313): Build fingerprint: 'Android/full_aries/aries:4.0.3/IML74K/eng.root.20120104.223924:userdebug/test-keys'
01-18 13:55:08.914: I/DEBUG(28313): pid: 31273, tid: 31276 >>> com.xxx.mcamera <<<
01-18 13:55:08.914: I/DEBUG(28313): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 48d20000
01-18 13:55:08.914: I/DEBUG(28313): r0 48d20000 r1 48b12040 r2 00019bc0 r3 00000000
01-18 13:55:08.914: I/DEBUG(28313): r4 408b19b8 r5 00000001 r6 0000001c r7 0000001c
01-18 13:55:08.914: I/DEBUG(28313): r8 41168000 r9 00000000 10 017f0cd8 fp 408afc58
01-18 13:55:08.914: I/DEBUG(28313): ip 408aaff0 sp 100ffe00 lr 408736c1 pc 40038b84 cpsr 20000010
01-18 13:55:08.914: I/DEBUG(28313): d0 0000000000000000 d1 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d2 0000000000000000 d3 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d4 0000000000000000 d5 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d6 0000000000000000 d7 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d8 0000000000000000 d9 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d10 0000000000000000 d11 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d12 0000000000000000 d13 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d14 0000000000000000 d15 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d16 0000000000000000 d17 3ff0000000000000
01-18 13:55:08.914: I/DEBUG(28313): d18 41b4f43b54000000 d19 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d20 0000000000000000 d21 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d22 0000000000000000 d23 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d24 0000000000000000 d25 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d26 0000000000000000 d27 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d28 0000000000000000 d29 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): d30 0000000000000000 d31 0000000000000000
01-18 13:55:08.914: I/DEBUG(28313): scr 80000012
01-18 13:55:09.074: I/DEBUG(28313): #00 pc 0000db84 /system/lib/libc.so (memcpy)
01-18 13:55:09.078: I/DEBUG(28313): #01 pc 0007b6be /system/lib/libdvm.so (_Z20dvmMarkImmuneObjectsPKc)
01-18 13:55:09.078: I/DEBUG(28313): #02 pc 00043604 /system/lib/libdvm.so (_Z18dvmHeapMarkRootSetv)
01-18 13:55:09.078: I/DEBUG(28313): #03 pc 000333f8 /system/lib/libdvm.so (_Z25dvmCollectGarbageInternalPK6GcSpec)
01-18 13:55:09.078: I/DEBUG(28313): #04 pc 0007ba40 /system/lib/libdvm.so
01-18 13:55:09.078: I/DEBUG(28313): #05 pc 0005f656 /system/lib/libdvm.so
01-18 13:55:09.078: I/DEBUG(28313): #06 pc 00012be4 /system/lib/libc.so (__thread_entry)
01-18 13:55:09.082: I/DEBUG(28313): #07 pc 00012738 /system/lib/libc.so (pthread_create)
01-18 13:55:09.082: I/DEBUG(28313): code around pc:
01-18 13:55:09.082: I/DEBUG(28313): 40038b64 3a000009 f5d1f080 f5d1f0c0 f5d1f100 ...:............
01-18 13:55:09.082: I/DEBUG(28313): 40038b74 f421020d f421420d f5d1f100 e2522040 ..!..B!.....@ R.
01-18 13:55:09.082: I/DEBUG(28313): 40038b84 f400022d f400422d 2afffff8 e2822040 -...-B.....*@ ..
01-18 13:55:09.082: I/DEBUG(28313): 40038b94 e2522020 3a000003 f421020d e2522020 R....:..!. R.
01-18 13:55:09.082: I/DEBUG(28313): 40038ba4 f400022d 2afffffb e2822020 e3120010 -......* ......
01-18 13:55:09.082: I/DEBUG(28313): code around lr:
01-18 13:55:09.082: I/DEBUG(28313): 408736a0 f8dc6ed9 1a50e030 020eebc2 6f580a01 .n..0.P.......Xo
01-18 13:55:09.082: I/DEBUG(28313): 408736b0 6e1b0a12 00920089 18591840 edf6f7a2 ...n....@.Y.....
01-18 13:55:09.082: I/DEBUG(28313): 408736c0 199e6823 1084f8d3 42916b32 f8c3bf38 #h......2k.B8...
01-18 13:55:09.082: I/DEBUG(28313): 408736d0 35012084 6d1a6823 d3d94295 81f0e8bd . .5#h.m.B......
01-18 13:55:09.082: I/DEBUG(28313): 408736e0 0003e32a b5104803 68004478 f7b73074 *....H..xD.ht0..
01-18 13:55:09.082: I/DEBUG(28313): memory map around addr 48d20000:
01-18 13:55:09.082: I/DEBUG(28313): 48d1d000-48d20000 /dev/ashmem/dalvik-bitmap-2 (deleted)
01-18 13:55:09.082: I/DEBUG(28313): 48d20000-48d22000 /datadata/ com.xxx.mcamera /adapterlib/libandroidadapter.so
01-18 13:55:09.082: I/DEBUG(28313): 48d22000-48d23000 /datadata/ com.xxx.mcamera /data/adapterlib/libandroidadapter.so
01-18 13:55:09.082: I/DEBUG(28313): stack:
01-18 13:55:09.086: I/DEBUG(28313): 100ffdc0 4088b3eb /system/lib/libdvm.so
01-18 13:55:09.086: I/DEBUG(28313): 100ffdc4 0c8b8700
01-18 13:55:09.086: I/DEBUG(28313): 100ffdc8 0000fa00
01-18 13:55:09.086: I/DEBUG(28313): 100ffdcc 4003be98 /system/lib/libc.so
01-18 13:55:09.086: I/DEBUG(28313): 100ffdd0 d84a2e1c
01-18 13:55:09.086: I/DEBUG(28313): 100ffdd4 00000005
01-18 13:55:09.086: I/DEBUG(28313): 100ffdd8 000003e8
01-18 13:55:09.086: I/DEBUG(28313): 100ffddc 000003e8
01-18 13:55:09.086: I/DEBUG(28313): 100ffde0 00000000
01-18 13:55:09.086: I/DEBUG(28313): 100ffde4 d84a2e1c
01-18 13:55:09.086: I/DEBUG(28313): 100ffde8 00000005
01-18 13:55:09.086: I/DEBUG(28313): 100ffdec 100ffe9c
01-18 13:55:09.086: I/DEBUG(28313): 100ffdf0 0187c748 [heap]
01-18 13:55:09.086: I/DEBUG(28313): 100ffdf4 408b19b8
01-18 13:55:09.086: I/DEBUG(28313): 100ffdf8 df0027ad
01-18 13:55:09.086: I/DEBUG(28313): 100ffdfc 00000000
01-18 13:55:09.086: I/DEBUG(28313): #00 100ffe00 48d1d000 /dev/ashmem/dalvik-bitmap-2 (deleted)
01-18 13:55:09.086: I/DEBUG(28313): 100ffe04 408736c1 /system/lib/libdvm.so
01-18 13:55:09.086: I/DEBUG(28313): #01 100ffe08 0187c6e8 [heap]
01-18 13:55:09.086: I/DEBUG(28313): 100ffe0c 0187c6e8 [heap]
01-18 13:55:09.086: I/DEBUG(28313): 100ffe10 408aaf90 /system/lib/libdvm.so
01-18 13:55:09.089: I/DEBUG(28313): 100ffe14 fffffe4c
01-18 13:55:09.089: I/DEBUG(28313): 100ffe18 7fffffff
01-18 13:55:09.089: I/DEBUG(28313): 100ffe1c 4083b608 /system/lib/libdvm.so
01-18 13:55:09.886: I/BootReceiver(219): Copying /data/tombstones/tombstone_02 to DropBox (SYSTEM_TOMBSTONE)
01-18 13:55:09.898: D/Zygote(160): Process 31273 terminated by signal (11)
01-18 13:55:09.906: I/ActivityManager(219): Process com.xxx.mcamera (pid 31273) has died.
yan-123456 2012-01-18
  • 打赏
  • 举报
回复
也遇到这个问题,就是load so出现的,不知道如何解决啊!!!!!
qthsrs232 2012-01-13
  • 打赏
  • 举报
回复
JNIEnv与jobject对象跨线程使用要特别处理!!!
xqhrs232 2012-01-11
  • 打赏
  • 举报
回复
当JNI遇到多线程--java对象如何被C++中的多个线程访问?
http://blog.csdn.net/hust_liuX/article/details/1460486
qthsrs232 2012-01-11
  • 打赏
  • 举报
回复
[Quote=引用 20 楼 qthsrs232 的回复:]
多线程间不能随便去使用JNIENV这个NDK公共对象指针

Chapter 8 Additional JNI Features
http://java.sun.com/docs/books/jni/html/other.html
[/Quote]



8.1.1 Constraints
There are certain constraints that you must keep in mind when writing native methods that are to run in a multithreaded environment. By understanding and programming within these constraints, your native methods will execute safely no matter how many threads simultaneously execute a given native method. For example:

A JNIEnv pointer is only valid in the thread associated with it. You must not pass this pointer from one thread to another, or cache and use it in multiple threads. The Java virtual machine passes a native method the same JNIEnv pointer in consecutive invocations from the same thread, but passes different JNIEnv pointers when invoking that native method from different threads. Avoid the common mistake of caching the JNIEnv pointer of one thread and using the pointer in another thread.
Local references are valid only in the thread that created them. You must not pass local references from one thread to another. You should always convert local references to global references whenever there is a possibility that multiple threads may use the same reference.

qthsrs232 2012-01-11
  • 打赏
  • 举报
回复
多线程间不能随便去使用JNIENV这个NDK公共对象指针

Chapter 8 Additional JNI Features
http://java.sun.com/docs/books/jni/html/other.html


qthsrs232 2012-01-11
  • 打赏
  • 举报
回复
[Quote=引用 17 楼 xqhrs232 的回复:]
觉得跨线程调用JNIENV上下文环境很容易出问题!!!
[/Quote]

Supporting JNI callbacks on a different thread / looking up JNIEnv correctly
http://www.experts-exchange.com/Programming/Languages/Java/Q_21281132.html


need to find a way to make a callback from C++ code to Java (through JNI) where the callback is on a different thread than the original call from Java that started the processing.

Let me explain that a bit more. Here's the sequence in psuedo code:

Java:
startOperation("myCallback") ; // This is a JNI call

void myCallback()
{
}

JNI/C++:
JNICALL JNI_startOperation(callbackName)
{
call-to-C-code-to-do-lots-of-stuff(&c_callback, data) ;
}

c_callback(data)
{
// Need to call back to "myCallback" in Java from here.
}

My current solution is in "JNI_startOperation" I store the JNIEnv* object I've been passed, record it with the callback and when the C++ callback occurs I retrieve it and use it to callback to Java through someting like: jenv->CallVoidMethod(). So far all is fine. The problem is if the callback is on a different thread than the original JNI_startOperation() this approach is no good because the cached JNIEnv* (I assume) is thread-specific and crashes the JVM when I try to use it.

So what I'm looking for is the proper way to look up this JNIEnv* object rather than caching it. I see methods about enumerating JVM's etc. in the JNI interface, but I'm not sure how to use them.

Anyone understand this stuff and can help walk me through it?

Doug



xqhrs232 2012-01-11
  • 打赏
  • 举报
回复
Signal 11 while compiling the kernel

http://www.bitwizard.nl/sig11/



ANSWER
Signal 11, or officially know as "segmentation fault", means that the program accessed a memory location that was not assigned. That's usually a bug in the program. So if you're writing your own program, that's the most likely cause. However, this FAQ will concentrate on the possibilities besides that.

xqhrs232 2012-01-11
  • 打赏
  • 举报
回复
[Quote=引用 23 楼 xqhrs232 的回复:]
Chapter 10 Traps and Pitfalls
http://java.sun.com/docs/books/jni/html/pitfalls.html#29161

C/C++ code


10.14 Using the JNIEnv across Threads
The JNIEnv pointer, passed as the first argument to……
[/Quote]




8.1.4 Obtaining a JNIEnv Pointer in Arbitrary Contexts
We explained earlier that a JNIEnv pointer is only valid in its associated thread. This is generally not a problem for native methods because they receive the JNIEnv pointer from the virtual machine as the first argument. Occasionally, however, it may be necessary for a piece of native code not called directly from the virtual machine to obtain the JNIEnv interface pointer that belongs to the current thread. For example, the piece of native code may belong to a "callback" function called by the operating system, in which case the JNIEnv pointer will probably not be available as an argument.

You can obtain the JNIEnv pointer for the current thread by calling the AttachCurrentThread function of the invocation interface:


JavaVM *jvm; /* already set */

f()
{
JNIEnv *env;
(*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL);
... /* use env */
}

When the current thread is already attached to the virtual machine, Attach-Current-Thread returns the JNIEnv interface pointer that belongs to the current thread.

There are many ways to obtain the JavaVM pointer: by recording it when the virtual machine is created, by querying for the created virtual machines using JNI_GetCreatedJavaVMs, by calling the JNI function GetJavaVM inside a regular native method, or by defining a JNI_OnLoad handler. Unlike the JNIEnv pointer, the JavaVM pointer remains valid across multiple threads so it can be cached in a global variable.

Java 2 SDK release 1.2 provides a new invocation interface function GetEnv so that you can check whether the current thread is attached to the virtual machine, and, if so, to return the JNIEnv pointer that belongs to the current thread. GetEnv and AttachCurrentThread are functionally equivalent if the current thread is already attached to the virtual machine.




xqhrs232 2012-01-11
  • 打赏
  • 举报
回复
Chapter 10 Traps and Pitfalls
http://java.sun.com/docs/books/jni/html/pitfalls.html#29161


10.14 Using the JNIEnv across Threads
The JNIEnv pointer, passed as the first argument to every native method, can only be used in the thread with which it is associated. It is wrong to cache the JNIEnv interface pointer obtained from one thread, and use that pointer in another thread. Section 8.1.4 explains how you can obtain the JNIEnv interface pointer for the current thread.


xqhrs232 2012-01-10
  • 打赏
  • 举报
回复
觉得跨线程调用JNIENV上下文环境很容易出问题!!!
xqhrs232 2012-01-10
  • 打赏
  • 举报
回复
今天又出现这样的CRASH。看来解决之道还很漫长啊!
树袋熊TRK 2011-12-05
  • 打赏
  • 举报
回复
留名,以后参考
xqhrs232 2011-04-25
  • 打赏
  • 举报
回复
[Quote=引用 13 楼 xqhrs232 的回复:]
把malloc( )++++free( )成对使用的情况换成一个预分配的数组,情况好很多啊!难道malloc( )++++free( )会造成内存碎片,使得free( )执行失败什么的!!!
[/Quote]

原来是对malloc( )函数的认识不足造成的,malloc( )函数是按字节数来分配内存空间的,所以分配INT的内存指针要记得在内存空间大小上乘以4才是正确的。以前没乘以4所以存在很多越界跟非法的操作!!!所以出现了上面的错误。
真的是技术都在细节啊!!!
xqhrs232 2011-04-23
  • 打赏
  • 举报
回复
把malloc( )++++free( )成对使用的情况换成一个预分配的数组,情况好很多啊!难道malloc( )++++free( )会造成内存碎片,使得free( )执行失败什么的!!!
xqhrs232 2011-04-23
  • 打赏
  • 举报
回复
好难找问题所在啊!一会是这个SO模块报错,一会是另外一个SO模块报错。
整了几天了还是找不到问题所在!!!
其实是一段蛮简单的代码!!!
qthsrs232 2011-04-21
  • 打赏
  • 举报
回复
Android signal 11 (SIGSEGV) Native Code crash 跟踪
http://apps.hi.baidu.com/share/detail/22489855
xqhrs232 2011-04-21
  • 打赏
  • 举报
回复
xqhrs232 2011-04-21
  • 打赏
  • 举报
回复
android 不再为ndk执行错误打出的一堆不知道什么意思的地址头疼了。
http://hi.baidu.com/dean_wang/blog/item/e83b2df210a375d77831aa46.html



终于找到如何解读ndk运行直接挂掉之后的错误地址,以后jni执行崩溃后除了加一堆的LOG就有新的方法调试 了。

如果logcat再一次打出如下的错误:

12-1022:20:04.839 I/DEBUG ( 551):************************************************
12-1022:20:04.839 I/DEBUG ( 551):Build fingerprint:'generic/sdk/generic/:1.5/CUPCAKE/150240:eng/test-keys'
12-1022:20:04.839 I/DEBUG ( 551): pid:1003, tid:1003 >>> com.example <<<
12-1022:20:04.849 I/DEBUG ( 551): signal 11(SIGSEGV), fault addr 00000004
12-1022:20:04.849 I/DEBUG ( 551): r0 00000000 r1 0019ed48 r2 00000001 r3 0019eae4
12-1022:20:04.859 I/DEBUG ( 551): r4 0019ea9c r5 0019ed48 r6 001935b0 r7 0000a9d0
12-1022:20:04.859 I/DEBUG ( 551): r8 00000001 r9 0019eae4 10804df39c fp 0019ea9c
12-1022:20:04.869 I/DEBUG ( 551): ip 00000071 sp beb6f4a8 lr 8041d8d9 pc 8041cc6c cpsr 00000030
12-1022:20:04.948 I/DEBUG ( 551): #00 pc 0000e3b4 /system/lib/libdvm.so
12-1022:20:04.948 I/DEBUG ( 551): stack:
12-1022:20:04.948 I/DEBUG ( 551): beb6f468 00000000
12-1022:20:04.959 I/DEBUG ( 551): beb6f46c 0019ede3 [heap]
12-1022:20:04.959 I/DEBUG ( 551): beb6f470 00000002
...

如果是以前,遇到这种情况是头疼的,不知道在哪挂掉了,之前只能在代码里面一句一句加log定位。


无意中发现了 http://source.android.com/

这是个让人惊喜的网站。主要面向系统程序员;里面大量介绍了android系统移植;(暂时不关我什么事);但是里面有篇文章介绍了如果debug native:

http://source.android.com/porting/debugging_native.html

很好。耐心读完 只见最关键一步在 Use the "stack" tool to convert these addresses to files and line numbers 这个就郁闷了。什么是 "stack" tool? 去sdk以及 各个地方好像都找不到。

外事不决问google;找到http://code.google.com/p/android-ndk-stacktrace-analyzer/

OK。具体怎么使用介绍的很详细。


xqhrs232 2011-04-21
  • 打赏
  • 举报
回复
加载更多回复(7)

80,465

社区成员

发帖
与我相关
我的任务
社区描述
移动平台 Android
androidandroid-studioandroidx 技术论坛(原bbs)
社区管理员
  • Android
  • yechaoa
  • 失落夏天
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧