On Sep 11, 11:14 am, fadden <fad...@android.com> wrote:
> On Sep 10, 6:20 pm, DaveG <david.golom...@flexilis.com> wrote:
>
> > With forcecopy enabled, I now get the crash in a different location:
>
> Interesting. Could be that whatever was trashing the virtual heap is
> now trashing the native heap. The guard areas are 256 bytes before/
> after, but if the write is outside that (or something is retaining a
> pointer and writing to it after the memory is freed) the problem
> wouldn't be detected.
Hmmm, after crashing in strlen() once, I'm back to getting the crash
in
System.gc() again (with d.v.checkjni = true and d.vjniopts = forcecopy
in my /data/local.props). I'm getting the crash in the same place in
my code every time, but I'm failing to see what might be wrong. Here
is
the code (should I move this thread to the NDK list?) that causes the
crash for me -- I don't see anything wrong, but maybe I'm missing
something about the ordering freeing of the resources?
jRet = (*jvm)->GetEnv(jvm, (void**)&env, JNI_VERSION_1_4);
if(jRet != JNI_OK) {
jRet = (*jvm)->AttachCurrentThread(jvm, &env, NULL);
DIE_IF(jRet != JNI_OK);
attachedThread = TRUE;
}
// clazz is a global ref to the class, cached earlier
jMethod = (*env)->GetStaticMethodID(env, clazz, "MyJavaMethod",
"(Ljava/lang/String;)Ljava/lang/String;");
DIE_IF(!jMethod);
jsParam = (*env)->NewStringUTF(env, "data");
DIE_IF(!jsParam);
jsReturn = (*env)->CallStaticObjectMethod(env, clazz, jMethod,
jsParam);
DIE_IF(!jsReturn);
output = (*env)->GetStringUTFChars(env, jsReturn, NULL);
DIE_IF(!output);
// Copy output into another buffer
if (jsParam) {
(*env)->DeleteLocalRef(env, jsParam);
}
if (output) {
(*env)->ReleaseStringUTFChars(env, jsReturn, output);
}
if (jsReturn) {
(*env)->DeleteLocalRef(env, jsReturn);
}
// Crash happens here (code only here to force crash, otherwise it
happens on next
// call to CallStaticObjectMethod)
systemClass = (*env)->FindClass(env, "java/lang/System");
gcFunc = (*env)->GetStaticMethodID(env, systemClass, "gc", "()V");
(*env)->CallStaticVoidMethod(env, systemClass, gcFunc);
if(attachedThread) {
(*jvm)->DetachCurrentThread(jvm);
}
> Could also be timing related -- forcecopy does tend to slow things
> down. What you really want here is valgrind, but I don't know of a
> version that works on ARM (though I've heard rumors).
Yeah, I'd LOVE to get valgrind on ARM.
> gdb's unwinding may be better, assuming that the stack itself wasn't
> trampled. You may also be able to find the saved LR on the stack,
> which is why a chunk from the top of the stack is also dumped out.
Yeah, unfortunately this is hard enough to reproduce that I haven't
gotten it to reproduce within gdb yet. Still hoping... It'd be great
to improve the stack unwinding code. Even the #00 address is sometimes
wrong for us, it seems to calculate the base address of our shared
library wrong and do the pc to #00 translation wrong. The pc is
correct,
#00 is off by 0xB0000 or so. That's easy enough to handle, but the
lack of a real stack makes post-mortem debugging painful.
> It's probably wise to ensure that you really are in strlen() by
> pulling libc.so off the device and checking it with arm-eabi-objdump -
> d. I hate it when the lib on the device isn't quite what I thought it
> was. :-) Curious that the fault address is 00000002 rather than a
> null pointer.
Unfortunately the libc.so on the device has no symbols so I can't
truly verify that -- is there a flag to objdump that I don't know
about that would help reverse resolve the address?
Thanks,
Dave Golombek
Flexilis, Inc
www.flexilis.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
