Fatal Signal (SIGSEGV) at 0xdeadbaad (code=1) Error solution (ANDROID-NDK)

When you do NDK programming on Android, you run into a random error.

The error message is as follows:

05-06 15:59:44.411:a/libc (3347): Fatal signal One (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.20130428.110435: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 (SIGSEGV), Code 1 (segv_maperr), fault addr Deadbaad
05-06 15:59:44.911:i/debug (3344): r0 deadbaad R1 00d9c060 R2 40000000 R3 00000000
05-06 15:59:44.911:i/debug (3344): R4 00000000 R5 00000027 R6 415bf010 R7 00000062
05-06 15:59:44.911:i/debug (3344): R8 415bf018 R9 00000047 100ffb94 FP 100ffbd8
05-06 15:59:44.911:i/debug (3344): IP ffffffff sp 100ffb50 lr 40071121 pc 4006d880 CPSR 60000030
05-06 15:59:44.911:i/debug (3344): D0 400000003eaaaaab d1 3ff000003f800000
05-06 15:59:44.911:i/debug (3344): D2 457ff80000000fff D3 000000003f000000
05-06 15:59:44.911:i/debug (3344): D4 00001fff00000000 d5 3fe999999999999a
05-06 15:59:44.911:i/debug (3344): D6 3ff0000000000000 D7 3eaaaaab3f800000
05-06 15:59:44.911:i/debug (3344): D8 0000000000000000 D9 0000000000000000
05-06 15:59:44.911:i/debug (3344): D10 0000000000000000 D11 0000000000000000
05-06 15:59:44.911:i/debug (3344): D12 0000000000000000 D13 0000000000000000
05-06 15:59:44.911:i/debug (3344): D14 0000000000000000 D15 0000000000000000
05-06 15:59:44.911:i/debug (3344): SCR 80000012
05-06 15:59:45.011:i/debug (3344): #00 pc 00017880/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 0007b746/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 (_z22dvmheapbitmapsweepwalkpk10heapbit MAPS1_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 (_z25dvmcollectgarbageinternalpk6gcspe C
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 0005f906/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 00012958/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): 4006d860 4623b15c 2c006824 e026d1fb b12368db \. #F $h.,.. &amp, .... h#.
05-06 15:59:45.011:i/debug (3344): 4006d870 21014a17 6011447a 48124798 24002527. J.! ZD. '. G.H '%.$
05-06 15:59:45.011:i/debug (3344): 4006d880 f7f47005 2106ee60 eeeef7f5 460aa901. P.. `..! ....... F
05-06 15:59:45.011:i/debug (3344): 4006d890 f04f2006 94015380 94029303 eab8f7f5. O.. S .....
05-06 15:59:45.011:i/debug (3344): 4006d8a0 4622a905 f7f52002 f7f4eac2 2106ee4c ... " F....... l..!
05-06 15:59:45.011:i/debug (3344): Code around LR:
05-06 15:59:45.011:i/debug (3344): 40071100 41f0e92d 46804c0c 447c2600 68a56824-.. a.l.f.&| D$h.h
05-06 15:59:45.011:i/debug (3344): 40071110 e0076867 300cf9b5 dd022b00 47c04628 gh ..... 0.+. (F.G
05-06 15:59:45.011:i/debug (3344): 40071120 35544306 37fff117 6824d5f4 d1ee2c00. CT5 ... 7.. $h.,..
05-06 15:59:45.011:i/debug (3344): 40071130 e8bd4630 bf0081f0 000283da 41f0e92d 0F ...-.. A
05-06 15:59:45.011:i/debug (3344): 40071140 fb01b086 9004f602 461f4815 4615460c ... 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 00000000
05-06 15:59:45.011:i/debug (3344): 100FFB2C 40071121/system/lib/libc.so
05-06 15:59:45.011:i/debug (3344): 100ffb30 00000000
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 00000062
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 00000000
05-06 15:59:45.021:i/debug (3344): #00 100ffb50 00000000
05-06 15:59:45.021:i/debug (3344): 100ffb54 00000000
05-06 15:59:45.021:i/debug (3344): 100ffb58 00000000
05-06 15:59:45.021:i/debug (3344): 100ffb5c 00000000
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 00000020
05-06 15:59:45.021:i/debug (3344): 100ffb6c 00000020
05-06 15:59:45.021:i/debug (3344): 100ffb70 00000000
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 00000062
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 40800749/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 2013 11:10: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={1015, 3003}
05-06 15:59:50.721:I/DALVIKVM (3441): Turning on JNI app bug workarounds for Target SDK version 9 ...

This error does not occur when a JNI interface is called again.

Instead, after repeated calls (or some other action on the top), the sudden jumps out.

The program doesn't have a frame, but the process is dead.

This stochastic problem is the hardest to figure out, and it's hard to determine which line of code is the problem

So all kinds of Baidu Google to find solutions

One of the most important error messages is Fatal signal (SIGSEGV) at 0xdeadbaad (code=1)

There are a lot of people on the internet who are having similar problems.

The main sticking point is the memory operation.

After a variety of troubleshooting tests, tossing the long time

Finally found the problem is the memory operation is wrong

In JNI, I want to convert Jbytearray into char*.

A conversion function was written, and the prototype was as follows:

[Java]View Plaincopy

2. <span style="FONT-SIZE:14PX;" >char* convertjbyteaarraytochars (jnienv *env, Jbytearray ByteArray, Jbyte *&bytes)
4. {
6. char *chars = NULL;
8. bytes = Env->getbytearrayelements (ByteArray, 0);
10. Chars = (char *) bytes;
12. int chars_len = Env->getarraylength (ByteArray);
14. Chars[chars_len] = 0;
16. return chars;
22. }</span>

The problem is

[Java]View Plaincopy

1. <span style="FONT-SIZE:14PX; Color:rgb (255, 0, 0); ">chars[chars_len] = 0;</span>

This sentence

If Getbytearrayelements is returning ABC,

The Chars_len value is 3

And chars[3]=0 is equal to the array out-of-bounds access modified

So invisible, it destroys the heap memory and leaves the program with a security risk.

Will trigger an error outbreak at a specific time.

After the function is changed to:

[Java]View Plaincopy

2. <span style="FONT-SIZE:14PX;" >char* convertjbyteaarraytochars (jnienv *env, Jbytearray ByteArray, Jbyte *&bytes)
4. {
6. char *chars = NULL;
8. bytes = Env->getbytearrayelements (ByteArray, 0);
10. int chars_len = Env->getarraylength (ByteArray);
12. chars = New Char[chars_len + 1];
14. memcpy (chars, Bytes, chars_len);
16. Chars[chars_len] = 0;
18. return chars;
20. }</span>

There's no problem.

After processing the char* at the calling function and then delete it, it's OK.

Oh, the pointers to C + + are really love and hate

We have a similar problem in the future

Well, check the native code.

See if there's a problem with the pointer being improperly

The pointer is risky and should be handled with caution

Only in this article small remember, hope to everyone helpful ~

Fatal Signal (SIGSEGV) at 0xdeadbaad (code=1) Error solution (ANDROID-NDK)