58cv网址导航Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
解决方案(android-ndk) - 推酷
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
解决方案(android-ndk)
在android里做ndk编程的时候，碰到个随机性错误
错误信息如下：
05-06 15:59:44.411: A/libc(3347): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
05-06 15:59:44.911: I/DEBUG(3344): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-06 15:59:44.911: I/DEBUG(3344): Build fingerprint: 'i.Kan/full_godbox/godbox:4.0.3/IML74K/eng.mipt.435:eng/test-keys'
05-06 15:59:44.911: I/DEBUG(3344): pid: 3347, tid: 3348 &&&& com.nef.xxx &&&
05-06 15:59:44.911: I/DEBUG(3344): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
05-06 15:59:44.911: I/DEBUG(3344): &r0 deadbaad &r1 00d9c060 &r2
05-06 15:59:44.911: I/DEBUG(3344): &r4
&r6 415bf010 &r7
05-06 15:59:44.911: I/DEBUG(3344): &r8 415bf018 &r9
100ffb94 &fp 100ffbd8
05-06 15:59:44.911: I/DEBUG(3344): &ip ffffffff &sp 100ffb50 &lr
05-06 15:59:44.911: I/DEBUG(3344): &d0 &eaaaaab &d1 &3ff000
05-06 15:59:44.911: I/DEBUG(3344): &d2 &457fffff &d3 &0000
05-06 15:59:44.911: I/DEBUG(3344): &d4 &00001fff &d5 &3fea
05-06 15:59:44.911: I/DEBUG(3344): &d6 &3ff0 &d7 &3eaaaaab3f800000
05-06 15:59:44.911: I/DEBUG(3344): &d8 &0000 &d9 &0000
05-06 15:59:44.911: I/DEBUG(3344): &d10 0000 &d11 0000
05-06 15:59:44.911: I/DEBUG(3344): &d12 0000 &d13 0000
05-06 15:59:44.911: I/DEBUG(3344): &d14 0000 &d15 0000
05-06 15:59:44.911: I/DEBUG(3344): &scr
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#00 &pc
&/system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#01 &pc 00007d8e &/system/lib/libcutils.so (mspace_free)
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#02 &pc
&/system/lib/libdvm.so (_Z21dvmHeapSourceFreeListjPPv)
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#03 &pc 00042f88 &/system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#04 &pc 00032fc8 &/system/lib/libdvm.so (_Z22dvmHeapBitmapSweepWalkPK10HeapBitmapS1_jjPFvjPPvS2_ES2_)
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#05 &pc 00042f44 &/system/lib/libdvm.so (_Z27dvmHeapSweepUnmarkedObjectsbbPjS_)
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#06 &pc 000336ac &/system/lib/libdvm.so (_Z25dvmCollectGarbageInternalPK6GcSpec)
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#07 &pc 0007bc1c &/system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#08 &pc
&/system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#09 &pc 00012e04 &/system/lib/libc.so (__thread_entry)
05-06 15:59:45.011: I/DEBUG(3344): & & & & &#10 &pc
&/system/lib/libc.so (pthread_create)
05-06 15:59:45.011: I/DEBUG(3344): code around pc:
05-06 15:59:45.011: I/DEBUG(3344): 3b15c 2c6d1fb b12368db &\.#F$h.,..&..h#.
05-06 15:59:45.011: I/DEBUG(3344): 14a17 02527 &.J.!zD.`.G.H'%.$
05-06 15:59:45.011: I/DEBUG(3344): fee60 eeeef7f5 460aa901 &.p..`..!.......F
05-06 15:59:45.011: I/DEBUG(3344): f0
eab8f7f5 &. O..S..........
05-06 15:59:45.011: I/DEBUG(3344):
f5eac2 2106ee4c &..&F. ......L..!
05-06 15:59:45.011: I/DEBUG(3344): code around lr:
05-06 15:59:45.011: I/DEBUG(3344): f0e92d 7c24 &-..A.L.F.&|D$h.h
05-06 15:59:45.011: I/DEBUG(3344): cf9b5 dd022b00 47c04628 &gh.....0.+..(F.G
05-06 15:59:45.011: I/DEBUG(3344): 44306 37fff117
d1ee2c00 &.CT5...7..$h.,..
05-06 15:59:45.011: I/DEBUG(3344): bd4630 bf283da 41f0e92d &0F..........-..A
05-06 15:59:45.011: I/DEBUG(3344):
fb01b086 fc &.........H.F.F.F
05-06 15:59:45.011: I/DEBUG(3344): memory map around addr deadbaad:
05-06 15:59:45.011: I/DEBUG(3344): be97c000-be99d000 [stack]
05-06 15:59:45.011: I/DEBUG(3344): (no map for address)
05-06 15:59:45.011: I/DEBUG(3344): ffff0000-ffff1000 [vectors]
05-06 15:59:45.011: I/DEBUG(3344): stack:
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb10 &4009965c &/system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb14 &00d9c060 &[heap]
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb18 &00000a96 &
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb1c &4006fecd &/system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb20 &4009970c &/system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb24 &4009e85c &
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb28 & &
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb2c & &/system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb30 & &
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb34 &100ffb64 &
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb38 &415bf010 &/dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb3c & &
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb40 &415bf018 &/dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb44 &4007028d &/system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): & & 100ffb48 &df0027ad &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb4c & &
05-06 15:59:45.021: I/DEBUG(3344): #00 100ffb50 & &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb54 & &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb58 & &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb5c & &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb60 &00cf2780 &[heap]
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb64 &fffffbdf &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb68 & &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb6c & &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb70 & &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb74 &40018d91 &/system/lib/libcutils.so
05-06 15:59:45.021: I/DEBUG(3344): #01 100ffb78 &00cf2780 &[heap]
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb7c &4162fe00 &/dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb80 &100ffcf4 &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb84 & &
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb88 &415bf018 &/dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.021: I/DEBUG(3344): & & 100ffb8c & &/system/lib/libdvm.so
05-06 15:59:45.661: I/BootReceiver(1265): Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_TOMBSTONE)
05-06 15:59:45.671: I/DEBUG(3344): debuggerd committing suicide to free the zombie!
05-06 15:59:45.671: I/DEBUG(3440): debuggerd: Apr 28 :17
05-06 15:59:45.681: D/Zygote(917): Process 3347 terminated by signal (11)
05-06 15:59:45.681: I/ActivityManager(1265): haveBgApp:true app.setAdj:10
05-06 15:59:45.681: I/ActivityManager(1265): Process com.nef.xxx (pid 3347) has died.
05-06 15:59:45.681: W/ActivityManager(1265): Scheduling restart of crashed service &com.nef.xxx/.service.renderService in 5000ms
05-06 15:59:48.241: D/PowerManagerService(1265): Screen must keep ON all the time! TimeoutTask return.
05-06 15:59:50.691: D/dalvikvm(3441): Late-enabling CheckJNI
05-06 15:59:50.701: I/ActivityManager(1265): Start proc com.nef.xxx for service com.nef.xxx/.service.renderService: pid=3441 uid=10009 gids={}
05-06 15:59:50.721: I/dalvikvm(3441): Turning on JNI app bug workarounds for target SDK version 9...
这个错误并不是再调用某个jni接口的时候发生的
而是反复调用之后（或是上层进行了一些其他操作后）冷不丁的蹦出来
程序虽然没有弹框，但进程已经挂了
这种随机问题最难搞了，很难确定哪行代码出的问题
于是各种百度谷歌寻求解决方案
其中最重要的错误信息是&
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
网上也有很多人都遇到类似的问题
主要症结还是内存操作的问题
在经过各种排查测试后，折腾了老半天
终于找到问题所在，的确是内存操作有误
在jni里，我想把jbyteArray转化成char*
于是写了个转化函数，原型如下：
char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray,
jbyte *&bytes)
char *chars = NULL;
bytes = env-&GetByteArrayElements(bytearray, 0);
chars = (char *)
int chars_len = env-&GetArrayLength(bytearray);
chars[chars_len] = 0;
问题就出在
chars[chars_len] = 0;
假如GetByteArrayElements返回的是abc
则chars_len值为3
而chars[3]=0就等于是数组越界访问修改了
这样无形当中就破坏了堆内存给程序留下安全隐患
到特定时候就会触发错误爆发
后函数改为：
char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray,
jbyte *&bytes)
char *chars = NULL;
bytes = env-&GetByteArrayElements(bytearray, 0);
int chars_len = env-&GetArrayLength(bytearray);
chars = new char[chars_len + 1];
memcpy(chars, bytes, chars_len);
chars[chars_len] = 0;
就没有问题了
在调用函数处处理了char*之后再delete掉就ok了
哎，C++的指针真是让人又爱又恨
以后大家遇到类似问题
还是好好检查下native代码
看看有没有指针操作不当的问题
指针有风险，用时需谨慎
仅以此文小记，希望对大家有帮助~
已发表评论数()
&&登&&&陆&&
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见notamonopoly
T03:51:06Z —
I am trying to call a non static java method from c++. Static calls work fine.
To accomplish this I have the following in c++
#include &jni.h&
JavaVM* javaVM = NULL;
jclass activityC
jobject activityO
JNIEXPORT void Java_com_thepackagename_theclassname_initJNIBridge(JNIEnv *env, jobject jobj){
env-&GetJavaVM(&javaVM);
jclass cls = env-&GetObjectClass(jobj);
activityClass = (jclass) env-&NewGlobalRef(cls);
activityObj = env-&NewGlobalRef(jobj);
void GameScene::purchaseItem(void) {
javaVM-&AttachCurrentThread(&env, NULL);
jmethodID method = env-&GetMethodID(activityClass, "UnlockGame", "(Ljava/lang/S)V");
jstring StringArg1 = env-&NewStringUTF("product1");
env-&CallVoidMethod(activityObj, method, StringArg1);
//env-&CallObjectMethod(activityObj, method, StringArg1);
The java method is:
void UnlockGame(String textStr){
Log.d(TAG, "UnlockGame CALLED!");
So in the java onCreate method of Cocos2dxActivity I call the initJNIBridge c++ method and everything is fine. Later, when I call the UnlockGame java method from c++ I get the following error:
A/libc(28959): Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 28974 (Thread-1031)
The error is on the actual CallVoidMethod line, if I comment it out it doesn't crash.
I have tried various ways to call UnlockGame including removing the arguments (from the signature and the call), tried CallVoidMethod and CallObjectMethod, nothing works. I have done a ndk-stack and it tells me nothing other than the app crashes in the purchaseItem method, which I already knew.
Can anyone suggest what I might be doing wrong?
T07:17:58Z —
#include//declare this as global will use this laterjclass activityC
JNIEnv thisE
jobject activityO
JNIEXPORT void Java_com_thepackagename_theclassname_initJNIBridge(JNIEnv *env, jobject jobj){
activityObj=
void GameScene::purchaseItem(void) {
JavaVM* javaVM ;
thisEnv-&getJavaVM(&javaVM);
javaVM-&AttachCurrentThread(&thisEnv, 0);
jclass cls = thisEnv-&GetObjectClass(activityObj);
jmethodID method = thisEnv-&GetMethodID(cls, "UnlockGame", "(Ljava/lang/S)V");
jstring StringArg1 = thisEnv-&NewStringUTF("product1");
env-&CallVoidMethod(activityObj, method, StringArg1);
//env-&CallObjectMethod(activityObj, method, StringArg1);
T07:19:08Z —
note dont put void GameScene::purchaseItem(){} inside of the Extern C
notamonopoly
T12:10:50Z —
Thanks for the reply.
I had previously tried moving GameScene::purchaseItem() outside of the Extern C but I will do it again. I think you're right about the global declarations. I wonder though why it allowed me to use the jclass and activityObj without crashing prior to making the call, like with activityClass here:
jmethodID method = env-&GetMethodID(activityClass, "UnlockGame", "(Ljava/lang/S)V");
In any case, I'm looking forward to trying the changes you suggest. I'm at work and won't be home until later today but I will post the results.
Thanks again for taking the time to reply and providing code, much appreciated.
notamonopoly
T01:53:05Z —
Well I don't know if this is progress or not but now I get a different error
Fatal signal 6 (SIGABRT) at 0x00002e42 (code=-6), thread 11858 (Thread-851)
And there is a warning in the log:
03-26 19:57:07.195: W/dalvikvm(11842): JNI WARNING: threadid=11 using env from threadid=1 (GetJavaVM)
03-26 19:57:07.195: W/dalvikvm(11842):
in Lorg/cocos2dx/lib/Cocos2dxR.nativeRender:()V (GetJavaVM)
03-26 19:57:07.205: I/dalvikvm(11842): "GLThread 851" prio=5 tid=11 NATIVE
03-26 19:57:07.205: I/dalvikvm(11842):
| group="main" sCount=0 dsCount=0 obj=0x423f9e40 self=0x730e4ca8
I set everything up to match your example, changing only the things that needed changing to allow it to compile, such as getJavaVM to GetJavaVM, etc.
When that didn't work I then tried changing things like using thisEnv to call the method instead of env.
Nothing is working and I've now wasted several days on this. Does anyone have a working example of making a non-static call from c++ to java (preferably using cocos2d-x). A really simple bare bones example that does nothing other than successfully call a method?
I've seen numerous examples but they all have code snippets that seem to leave out important details as I can't get it to work. That's where my original code was from, an example on another site .
T03:05:31Z —
here is how I call my java function in c++ using jni
JavaVM * //this is important to avoid threading errors thisEnv-&GetJavaVM(&jvm); //this is important to avoid threading errors jvm-&AttachCurrentThread(&thisEnv, 0); //this is important to avoid threading errors //jstring jstr = thisEnv-&NewStringUTF("From jni"); jclass cls = thisEnv-&GetObjectClass(thisObj); jmethodID method = thisEnv-&GetMethodID(cls, "methodFromJAVA","(Ljava/lang/S)V"); jobject result = thisEnv-&CallObjectMethod(thisObj, method);
note: "env-&CallVoidMethod(activityObj, method, StringArg1)" remove this line in your code, there's no need for you to use this, by calling this line
"thisEnv-&GetMethodID(cls, "methodFromJAVA","(Ljava/lang/S)V");" you are already specifying that your code is void and has a string parameter
notamonopoly
T02:53:47Z —
To simplify things I created a new HelloWorld project called jnitest.
This is the relevant part of the cpp file
#include "HelloWorldScene.h"
#if (CC_TARGET_PLATFORM == CC_PLATFORM_ANDROID)
#include "platform\android\jni\JniHelper.h"
USING_NS_CC;
#if (CC_TARGET_PLATFORM == CC_PLATFORM_ANDROID)
jclass activityC
jobject activityO
JNIEnv* thisE
JNIEXPORT void JNICALL Java_com_testing_jnitest_jnitest_initJNIBridge(JNIEnv *env, jobject jobj){
activityObj=
void HelloWorld::makeJniCall(void) {
JavaVM * //this is important to avoid threading errors
thisEnv-&GetJavaVM(&jvm); //this is important to avoid threading errors
jvm-&AttachCurrentThread(&thisEnv, 0); //this is important to avoid threading errors
jclass cls = thisEnv-&GetObjectClass(activityObj);
jmethodID method = thisEnv-&GetMethodID(cls, "UnlockGame","(Ljava/lang/S)V");
jobject result = thisEnv-&CallObjectMethod(activityObj, method);
And the result from calling makeJniCall:
03-27 21:38:44.239: W/dalvikvm(19263): JNI WARNING: threadid=11 using env from threadid=1 (GetJavaVM)
03-27 21:38:44.239: E/dalvikvm(19263): JNI ERROR: env-&self != thread-self (0x416a75d0 vs. 0x73bb3aa8); auto-correcting
03-27 21:38:44.239: A/libc(19263): Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 19278 (Thread-986)
I believe I've done everything you've suggested. Am I missing something. Do you have any other suggestions, or possibly a full working example (.cpp and .java file)?
T03:57:01Z —
okay here is my working code
T03:57:16Z —
and the java code
T04:00:31Z —
in java code look for these functions:methodFromJAVA()-&java/android function that will call camera intentgetPath()-&this will return a string
in c++ code look for the following method:HelloWorld::printSomethingFromJava()-&this will call the methodfromjava HelloWorld::displayImage()-&this will call the getPath
hope it helps
T04:01:31Z —
can I also see your java code?if its okay
T05:18:40Z —
please also take note: public native void initJNIBridge();-&this is the native function that connect your java to c++
be sure that you call this method inside of your java call it's either in onCreate() or onResume(), else you'll get an error.
notamonopoly
T12:20:14Z —
Wow, thanks. That's more than I was expecting. I just got to work but I will look at it later today and see if I can get my code to finally work.
I can show you my java code as well. I didn't include it before because there wasn't anything in it except the UnlockGame
method and a call to initJNIBridge in the onCreate method, but I should have added it here to be complete.
Just taking a quick look it seems that I have my code setup the same way as yours but if yours works then it's clearly something I've done wrong.
I will let you know when I get it working. Thanks again for following up, you've already been a big help.
notamonopoly
T03:05:37Z —
I finally got it working!
Using the relevant parts from your code I was able to successfully make a non-static call to Java from C++. I did get an error, though the app didn't crash:
03-28 21:44:24.673: W/dalvikvm(20566): JNI WARNING: threadid=11 using env from threadid=1 (GetJavaVM)
03-28 21:44:24.673: E/dalvikvm(20566): JNI ERROR: env-&self != thread-self (0x415ba5f8 vs. 0x); auto-correcting
So after doing some research I created a global reference to the jvm when making the first jni call and then reuse it in all other calls.
JNIEnv* thisE
jobject thisO
extern "C" {
JNIEXPORT jstring JNICALL
Java_com_testing_jnitest_jnitest_stringFromJNI(JNIEnv *env, jobject obj)
env-&GetJavaVM(&jvm);
return env-&NewStringUTF("Hello from C++ over JNI!");
void HelloWorld::displayImage() {
jvm-&AttachCurrentThread(&thisEnv, 0); //this is important to avoid threading errors
jclass cls = thisEnv-&GetObjectClass(thisObj);
jmethodID method = thisEnv-&GetMethodID(cls, "getPath","()Ljava/lang/S");
jstring result = (jstring) thisEnv-&CallObjectMethod(thisObj, method);
The java wasn't changed much from your code.
public class jnitest extends Cocos2dxActivity{
//JNI method
public native String stringFromJNI();
public String path = "Testing";
protected void onCreate(Bundle savedInstanceState){
super.onCreate(savedInstanceState);
System.out.println("The string = " + stringFromJNI());
public Cocos2dxGLSurfaceView onCreateView() {
Cocos2dxGLSurfaceView glSurfaceView = new Cocos2dxGLSurfaceView(this);
// jnitest should create stencil buffer
glSurfaceView.setEGLConfigChooser(5, 6, 5, 0, 16, 8);
return glSurfaceV
System.loadLibrary("cocos2dcpp");
public String getPath(){
System.out.println("getPath Called!");
Thank you so much for all your help. This was driving me absolutely nuts!
T13:19:54Z —
Your welcome sir
T04:53:03Z —
Hey Guys, I just experienced a very similar problem after I updated to Cocos2dxActivity from NativeActivity. (based on cocos2d-develop code)
The error I'm getting is the standard memory issue Fatal Signal 11 (SIGSEGV). I tracked it down to the JNI call from the renderer, which fails trying to do callback the cocos director, but works just fine with random code.
JNIEXPORT void JNICALL Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeOnResume() {
but fails when I try to get
the original cocos calls.
JNIEXPORT void JNICALL Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeOnResume() {
if (Director::getInstance()-&getOpenGLView()) {
Application::getInstance()-&applicationWillEnterForeground();
Here is my main activity.
public class AEActivity extends Cocos2dxActivity {
public Cocos2dxGLSurfaceView onCreateView() {
Cocos2dxGLSurfaceView glSurfaceView = new Cocos2dxGLSurfaceView(this);
// TestCpp should create stencil buffer
glSurfaceView.setEGLConfigChooser(5, 6, 5, 0, 16, 8);
return glSurfaceV
I'd be super grateful for any hints.
T02:15:00Z —
Did you ever discover a solution? I believe I'm running into something similar.
T04:15:49Z —
Yes, I believe this was due to the Java activity they used. They then reverted back to the original. I think they introduced it in 3.0beta and went back to the simple one in 3.0rc0. I'm a little hazy on details since it's been a while. If you really get stuck and this doesn't help, I can probably look at my code.
T00:36:52Z —
Thanks for the prompt response.
I solved my problem and it turns out it was unrelated to this. It had something to do with building JNI signatures and package names programmatically (still not 100% sure).