Getting the signal 11 (SIGSEGV), fault addr deadbaad

[Amit Chauhan]

Hi,

I am building one c\c++ native application for android, trying to run
it android but getting following error.

D/libc-abort( 7254): abort() called in pid 7254
I/DEBUG ( 28): *** *** *** *** *** *** *** *** *** *** *** *** ***
*** *** *
**
I/DEBUG ( 28): Build fingerprint: 'generic/sdk/generic/:1.6/Donut/
20842:eng/
test-keys'
I/DEBUG ( 28): pid: 7254, tid: 7254 >>>
com.keypoint_tech.adaptxt.inputmeth
od.core.testAdaptxt <<<
I/DEBUG ( 28): signal 11 (SIGSEGV), fault addr deadbaad
I/DEBUG ( 28): r0 00000003 r1 deadbaad r2 00000027 r3 ffff629c
I/DEBUG ( 28): r4 ffff6274 r5 afe30048 r6 afe39dd4 r7 00000000
I/DEBUG ( 28): r8 00000062 r9 457a1900 10 42493900 fp befdc254
I/DEBUG ( 28): ip 0000001b sp befdbf78 lr afe2000b pc
afe1072a cpsr 200
00030
I/DEBUG ( 28): #00 pc 0001072a /system/lib/libc.so
I/DEBUG ( 28): #01 pc 0000640e /system/lib/libcutils.so
I/DEBUG ( 28): #02 pc 00049168 /system/lib/libdvm.so
I/DEBUG ( 28): #03 pc 00015d90 /system/lib/libdvm.so
I/DEBUG ( 28): #04 pc 0001476c /system/lib/libdvm.so
I/DEBUG ( 28): #05 pc 00014dfc /system/lib/libdvm.so
I/DEBUG ( 28): #06 pc 00015cb4 /system/lib/libdvm.so
I/DEBUG ( 28): #07 pc 00015424 /system/lib/libdvm.so
I/DEBUG ( 28): #08 pc 0001583c /system/lib/libdvm.so
I/DEBUG ( 28): #09 pc 000159a4 /system/lib/libdvm.so
I/DEBUG ( 28): #10 pc 0005a90c /system/lib/libdvm.so
I/DEBUG ( 28): #11 pc 0005aa2c /system/lib/libdvm.so
I/DEBUG ( 28): #12 pc 0005ab2c /system/lib/libdvm.so
I/DEBUG ( 28): #13 pc 00024918 /system/lib/libdvm.so
I/DEBUG ( 28): #14 pc 000176dc /system/lib/libdvm.so
I/DEBUG ( 28): #15 pc 0005275e /system/lib/libdvm.so
I/DEBUG ( 28): #16 pc 000397ba /system/lib/libdvm.so
I/DEBUG ( 28): #17 pc 00053e42 /system/lib/libdvm.so
I/DEBUG ( 28): #18 pc 000544c8 /system/lib/libdvm.so
I/DEBUG ( 28): #19 pc 00039c10 /system/lib/libdvm.so
I/DEBUG ( 28): #20 pc 0001e874 /system/lib/libdvm.so
I/DEBUG ( 28): #21 pc 0002943c /system/lib/libdvm.so
I/DEBUG ( 28): #22 pc 000176dc /system/lib/libdvm.so
I/DEBUG ( 28): #23 pc 000529a8 /system/lib/libdvm.so
I/DEBUG ( 28): #24 pc 00059eda /system/lib/libdvm.so
I/DEBUG ( 28): #25 pc 00013198 /system/lib/libdvm.so
I/DEBUG ( 28): #26 pc 00017be4 /system/lib/libdvm.so
I/DEBUG ( 28): #27 pc 0001762c /system/lib/libdvm.so
I/DEBUG ( 28): #28 pc 0005282c /system/lib/libdvm.so
I/DEBUG ( 28): #29 pc 0003f790 /system/lib/libdvm.so
I/DEBUG ( 28): #30 pc 00031caa /system/lib/libdvm.so
I/DEBUG ( 28): #31 pc 0002a804 /system/lib/
libandroid_runtime.so
I/DEBUG ( 28): stack:
I/DEBUG ( 28): befdbf38 000b1210 [heap]
I/DEBUG ( 28): befdbf3c afe12f59 /system/lib/libc.so
I/DEBUG ( 28): befdbf40 afe3cdf0
I/DEBUG ( 28): befdbf44 afe39ff0 /system/lib/libc.so
I/DEBUG ( 28): befdbf48 0000000e
I/DEBUG ( 28): befdbf4c afe13f0d /system/lib/libc.so
I/DEBUG ( 28): befdbf50 000006f9
I/DEBUG ( 28): befdbf54 6732b1fe
I/DEBUG ( 28): befdbf58 befdc084 [stack]
I/DEBUG ( 28): befdbf5c ffff6274
I/DEBUG ( 28): befdbf60 afe30048 /system/lib/libc.so
I/DEBUG ( 28): befdbf64 afe39dd4 /system/lib/libc.so
I/DEBUG ( 28): befdbf68 00000000
I/DEBUG ( 28): befdbf6c afe10723 /system/lib/libc.so
I/DEBUG ( 28): befdbf70 df002777
I/DEBUG ( 28): befdbf74 e3a070ad
I/DEBUG ( 28): #00 befdbf78 000244e4 [heap]
I/DEBUG ( 28): befdbf7c 80696b83 /data/data/
com.keypoint_tech.adaptxt.
inputmethod.core.testAdaptxt/lib/libkptframeworkv2.so
I/DEBUG ( 28): befdbf80 0000000c
I/DEBUG ( 28): befdbf84 befdc084 [stack]
I/DEBUG ( 28): befdbf88 0000000c
I/DEBUG ( 28): befdbf8c fffffbdf
I/DEBUG ( 28): befdbf90 400092e0 /dev/ashmem/mspace/dalvik-
heap/zygote
/0 (deleted)
I/DEBUG ( 28): befdbf94 439afab0 /dev/ashmem/mspace/dalvik-
heap/2 (del
eted)
I/DEBUG ( 28): befdbf98 4374c018 /dev/ashmem/mspace/dalvik-
heap/2 (del
eted)
I/DEBUG ( 28): befdbf9c afb06413 /system/lib/libcutils.so
I/DEBUG ( 28): #01 befdbfa0 4374c010 /dev/ashmem/mspace/dalvik-
heap/2 (del
eted)
I/DEBUG ( 28): befdbfa4 000001e0
I/DEBUG ( 28): befdbfa8 00000001
I/DEBUG ( 28): befdbfac 400092e0 /dev/ashmem/mspace/dalvik-
heap/zygote
/0 (deleted)
I/DEBUG ( 28): befdbfb0 439afab8 /dev/ashmem/mspace/dalvik-
heap/2 (del
eted)
I/DEBUG ( 28): befdbfb4 400092c8 /dev/ashmem/mspace/dalvik-
heap/zygote
/0 (deleted)
I/DEBUG ( 28): befdbfb8 00000000
I/DEBUG ( 28): befdbfbc ad04916b /system/lib/libdvm.so
D/Zygote ( 30): Process 7254 terminated by signal (11)


I tried to use arm-eabi-addr2line with address 0001072a than i got the
following result

/usr/local/google/home/digit/android/main/cupcake/android/bionic/libc/
unistd/brk.c:45

can anyone help me to solve this problem. && i am getting this for all
platform Android 1.6, 2.1, and 2.2.

Thanks
Amit

[Mike Edenfield]

On 2/11/2011 1:14 AM, Amit Chauhan wrote:
> Hi,
>
> I am building one c\c++ native application for android, trying to run
> it android but getting following error.

> I/DEBUG ( 28): pid: 7254, tid: 7254 >>>

> com.keypoint_tech.adaptxt.inputmeth
> od.core.testAdaptxt <<<
> I/DEBUG ( 28): signal 11 (SIGSEGV), fault addr deadbaad

A fault address of deadbaad is a signal that your problem is a corrupt
memory heap. The error's going to come from libc, but that's just
because libc's memory management routines are what ultimately triggered
the fault, not because libc itself is buggy. The most likely cause is
somewhere in your code that you're calling free() or delete on something
you don't own, or have already released. That's causing heap corruption
that breaks things later on down the road.

> I/DEBUG ( 28): #00 pc 0001072a /system/lib/libc.so
> I/DEBUG ( 28): #01 pc 0000640e /system/lib/libcutils.so

> I tried to use arm-eabi-addr2line with address 0001072a than i got the

> following result
>
> /usr/local/google/home/digit/android/main/cupcake/android/bionic/libc/
> unistd/brk.c:45

Running addr2line on libc isn't likely to give you much useful
information, you're almost always going to get a reference to brk() or
dlfree() or some other low-level memory management function.

In general you'll want to skip down the stack trace to your shared
library, and run addr2line on that entry (libcutils.so 0x0000640e). But
with this kind of fault, the actual source of the bug is probably
somewhere else in your code, and the faulting address just happens to be
the first time the bionic library detected something wrong.

--Mike

[Amit Chauhan]

Hi Mike,

 

First of all thanks a lot But could you please suggest something how I should approach this problem. OR any help for debugging.

 

Thanks

Amit

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[alan]

as most of the stack is from dalvik that would suggest maybe a problem with your jni code is corrupting dalvik's memory. examples could include, accessing a garbage collected object, overflowing or underflowing an array. turning checkjni on may indicate what the problem is

[fadden]

On Feb 11, 7:07 am, Mike Edenfield <kut...@kutulu.org> wrote:
> A fault address of deadbaad is a signal that your problem is a corrupt
> memory heap.  The error's going to come from libc, but that's just
> because libc's memory management routines are what ultimately triggered
> the fault, not because libc itself is buggy.  The most likely cause is
> somewhere in your code that you're calling free() or delete on something
> you don't own, or have already released.  That's causing heap corruption
> that breaks things later on down the road.

Actually, deadbaad is what the libc abort() function uses to kill the
process. 99% of the time the code calling abort() is in malloc/free,
but it's certainly possible that something else could be calling it.

My recommendation to anyone doing native development is to make sure
CheckJNI is enabled (it's on by default in the emulator, and you can
turn it on with "setprop dalvik.vm.checkjni true ; stop ; start" on a
rooted device). You can also try some of the enhanced memory checking
modes. "setprop libc.debug.malloc 10" will turn on some native heap
malloc guards, and "setprop dalvik.vm.jniopts forcecopy" will add some
memory buffer protection to CheckJNI.

See also:
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/jni-tips.html;hb=HEAD
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/embedded-vm-control.html;hb=HEAD

[Amit Chauhan]

Hi,

What is happening in my case, My program getting crash when i am trying to retrieve the values from buffer which is populated in JNI side.

Here is following code i am using to get the value from JNI side populated buffer.

for(int j = 0; j < count; j++)
{
                    len = outBuf.getInt();
                    CharBuffer cbuf = outBuf.asCharBuffer();
                    CharSequence cS = cbuf.subSequence(0, len);
                    wordsPage[j] = cS.toString();
                    outBuf.position(outBuf.position()+ (len*2));
  }

And could you please tell me any full proof mechanism to share the memory between Java and JNI.

[alan]

the error is much more likely to be in your native code than your java code, if the java code was wrong i would expect it to throw a java exception

[Amit Chauhan]

Hi,

Even i tried to put the code in try - catch block but it is not getting caught.
And second thing  how to verify that my native code is wrong because in native i am using malloc and i am doing NULL checking  also.

And it is returning successfully from JNI side code. If i comment following code

for(int j = 0; j < count; j++)
{
                    len = outBuf.getInt();
                    CharBuffer cbuf = outBuf.asCharBuffer();
                    CharSequence cS = cbuf.subSequence(0, len);
                    wordsPage[j] = cS.toString();
                    outBuf.position(outBuf.

position()+ (len*2));
}

It is running successfully.In JNI i am using NewDirectByteBuffer to create the object from memory.

Thanks
Amit

On Mon, Feb 14, 2011 at 3:30 PM, alan <al...@birtles.org.uk> wrote:

the error is much more likely to be in your native code than your java code, if the java code was wrong i would expect it to throw a java exception

--

[alan]

your native code is probably somehow corrupting outbuf, if you never use outbuf then the corruption will go unnoticed. you can't catch a native error like a segmentation fault in java, the vm will just die and even if you could catch the error then the vm would likely be unstable.
no body will be able to tell you what is wrong with your native code without seeing it! your java code looks ok and if it wasn't im sure you would get a java exception rather than a seg fault.

[Amit Chauhan]

HI All,


Thanks a lot for you people's help this issue has been fixed there was some problem in my native code.

But still i want to set up the debugging environment for android-ndk so that i can step in native code and debug that. So it would be help full any one can provide the some good link for this.

Thanks
Amit
 

On Mon, Feb 14, 2011 at 6:39 PM, alan <al...@birtles.org.uk> wrote:

your native code is probably somehow corrupting outbuf, if you never use outbuf then the corruption will go unnoticed. you can't catch a native error like a segmentation fault in java, the vm will just die and even if you could catch the error then the vm would likely be unstable.
no body will be able to tell you what is wrong with your native code without seeing it! your java code looks ok and if it wasn't im sure you would get a java exception rather than a seg fault.

[James Moore]

On Feb 15, 8:30 pm, Amit Chauhan <amitchauhan....@gmail.com> wrote:
> But still i want to set up the debugging environment for android-ndk so that
> i can step in native code and debug that. So it would be help full any one
> can provide the some good link for this.

It's in the NDK files -

android-ndk-r5b/documentation.html

and then look at the "NDK GDB" section.

There's documentation scattered around the web for integrating it with
Eclipse, but it looked pretty painful to me. gdb by itself is good
enough. (And if you're like me, and haven't used gdb for a long, long
time, it's now got a curses mode. Try "layout src".)