DVM thread model - JNI Question

[ashutosh...@gmail.com]

I am developing an Android application(APK) that loads a shared
library compiled with android toolchain, after which it calls(JNI) the
init native method(definition resides in .so), the init native method
spawns six threads (using pthread). The UI Java code posts messages
which are processed by the native threads by calling a nativePost
method using JNI. One of the native thread calls Java code to post
message in Java thread(green thread) using the Java Invocation method
to inform the job done status.

My Android application sometimes crashes anywhere and sometimes works,
I was suspecting a possible memory corruption which I could not find
but I have also a basic question about my design.

What is the life span of a native thread created during a JNI call in
Android? Does the thread die after the JNI call returns? I do not see
any native threads for my application in DDMS. But I can verify from
the logcat that native threads get created successfully and are able
to process messages.

I am testing on Emulator.

Section 8.1.5 Matching the Thread Models (http://java.sun.com/docs/
books/jni/html/other.html), speaks about the thread model that a Java
VM implements, I want to know what thread model DVM implements?


Thanks In Advance
Ashutosh

[Andreas Kostyrka]

Some stupid question, because that seems to be missing your description. How does your handle it's process dieing, which can happen in Android in a number of situations? And I think that only because your Activity has been notified to finish that does not mean that your process will die for sure.

Andreas

[ashutosh...@gmail.com]

Did you actually understand the question?
Request somebody to reply who undertsand the question!

On Jun 19, 11:03 am, Andreas Kostyrka <yacc...@gmail.com> wrote:
> Some stupid question, because that seems to be missing your description. How
> does your handle it's process dieing, which can happen in Android in a
> number of situations? And I think that only because your Activity has been
> notified to finish that does not mean that your process will die for sure.
>
> Andreas
>

> 19. Jun 2009 7:47 vorm. schrieb am "ashutoshkagra...@gmail.com" <
> ashutoshkagra...@gmail.com>:

[David Given]

ashutosh...@gmail.com wrote:
> I am developing an Android application(APK) that loads a shared
> library compiled with android toolchain, after which it calls(JNI) the
> init native method(definition resides in .so)

[...]

> One of the native thread calls Java code to post
> message in Java thread(green thread) using the Java Invocation method
> to inform the job done status.

[...]

Dalvik doesn't use green threads --- each Java thread is just a pthreads
thread.

This means that you'll get horrible race conditions if you try to call
the VM from a thread it wasn't expecting. To avoid this, register your
new pthreads with the VM using the *jvm->AttachCurrentThread() call.

--
David Given
d...@cowlark.com

[fadden]

On Jun 19, 8:10 am, David Given <d...@cowlark.com> wrote:
> Dalvik doesn't use green threads --- each Java thread is just a pthreads
> thread.
>
> This means that you'll get horrible race conditions if you try to call
> the VM from a thread it wasn't expecting. To avoid this, register your
> new pthreads with the VM using the *jvm->AttachCurrentThread() call.

If you're doing anything with JNI, you really, really want to have
"check JNI" enabled. See dalvik/docs/embedded-vm-control.html.

Among other things, it will politely notify you if you're sharing a
JNIEnv between multiple threads, which can lead to all sorts of
bizarre problems. And then it will politely abort. :-)

See also dalvik/docs/jni-tips.html.

[ashutosh...@gmail.com]

Thanks for replying, this info is useful..
On further debugging I could find that my application crashes much
before when native code calls the VM, and it doesnot even crash during
the JNI call, it crashes in the native code during a queue operation,
due to memory corruption. I have unit tested that part of code
successfully on Android, and not able to find the corruption, can you
suggest some tool/method to find it? BTW, I am extensively using
pthread API(thread,mutex,conditions,etc) which are available in
Bionic, are these APIs stable?

Thanks
Ashutosh

[David Turner]

On Sun, Jun 21, 2009 at 7:20 PM, ashutosh...@gmail.com <ashutosh...@gmail.com> wrote:

BTW, I am extensively using
pthread API(thread,mutex,conditions,etc) which are available in
Bionic, are these APIs stable?

Yes they are.
 

Thanks
Ashutosh

[fadden]

On Jun 21, 10:20 am, "ashutoshkagra...@gmail.com"

<ashutoshkagra...@gmail.com> wrote:
> On further debugging I could find that my application crashes much
> before when native code calls the VM, and it doesnot even crash during
> the JNI call, it crashes in the native code during a queue operation,
> due to memory corruption. I have unit tested that part of code
> successfully on Android, and not able to find the corruption, can you
> suggest some tool/method to find it?

Build it for x86 and run it under valgrind.

[ashutosh...@gmail.com]

Hi!!

Even with putting lot of effort to find the reason for crash, I could
not find any :(
I could not even run it with valgrind because I could not make it
working for me on Android cupcake 1.5.
Here is the problem description again

I have a Java application (apk), on one of the button press I invoke
an init function which calls native init function using JNI. All init
functions are

int Init(void)

In the native init function - I create threads (using pthread) and
return, and each thread does some local initializations, these threads
communicate with each other using queues using POSIX (conditional
variables and mutex).

Native code never invokes VM.

I observe the crash when my JAVA init method returns after
successfully calling the native init function; I get the crash call
stack through ddms and doing grep with arm-eabi-nm gives me always a
different call stack but always in mynativelib.so. Sometimes I have
observed crash in malloc, __FILE__ also.

If I run a native application (NATIVE-APP) through adb shell on
Android and do dlopen to the same mynativelib.so, and call my native
init, it always work and never crashes. I could not crash my native
application after repeating same steps for a significant number (20)
of times with clean builds (4/5 times).

I have observed a funny behavior in my JAVA application, every third
time my application does not crash. I do use persistent object/memory
but all of them are readonly(I am not writing to them from my
program).

I tried using checkjni, but the behavior is same and I don't get any
additional information on ddms.

The size of mynativelib.so is 13M, is that a problem? I can see even
bigger .so in system/lib

My native code which runs in the context of multiple threads has lot
of static variables, could that be a problem? If so why it works
properly from NATIVE-APP all the time?I have observed the same thread
execution sequence on both the cases(native app and Java app).

I am creating threads in detached state with default 1MB stack size.
Can that be a problem?

Am I missing anything? Actually I just followed the development/
samples/PlatformLibrary. I have tested successfully my JAVA code
without native (JNI).

Any directions to solve the crash will be great help!!


Thanks
Ashutosh

[ashutosh...@gmail.com]

I could fix the crash :), now I need to confirm if what I found could
really be the cause -

I found that all the shared libraries that were into /system/lib does
not have definitions for malloc and free, this I confirmed by doing
arm-eabi-nm on their respective shared libraries in their out/
intermediate folder, where as mynativelib.so was having definitions
for malloc and free because I was building my shared library by
statically linking with libc.

According to my understanding, malloc & free are mapped with function
pointers in shared library and during the load time these function
pointers for malloc and free gets mapped with actual malloc and free
definitions. Is that understanding correct and holds good for android
too?

When I removed the statically linking with libc from Android.mk, I
could not observe any crash. Can somebody confirm this as a possible
cause for crash?


Thanks
Ashutosh