Our stacks in places like bug 747787 from Fennec Java crashes tend not to be very forthcoming: Thread 1 (crashed) 0 libc.so + 0xa848 r4 = 0x00144088 r5 = 0xafd438e4 r6 = 0xafd42328 r7 = 0xafd43728 r8 = 0x00100000 r9 = 0x8084f09d r10 = 0x10000000 fp = 0x0013db30 sp = 0x100ffe28 lr = 0xafd0a82b pc = 0xafd0a848 Found by: given as instruction pointer in context 1 libdvm.so + 0x50be3 sp = 0x100ffe2c pc = 0x80850be5 Found by: stack scanning 2 libdvm.so + 0xa13f2 sp = 0x100ffe38 pc = 0x808a13f4 Found by: stack scanning 3 0 (deleted) + 0x34e sp = 0x100ffe3c pc = 0x40009350 Found by: stack scanning 4 libdvm.so + 0x50bd3 sp = 0x100ffe48 pc = 0x80850bd5 Found by: stack scanning 5 libdvm.so + 0xa13f2 sp = 0x100ffe50 pc = 0x808a13f4 Found by: stack scanning Rumor has it that we could do better, because <ted>: since we stick a JavaStack field in the .extra file... <ted>: (it's what socorro uses instead)

"JavaStackTrace" is the name of the actual field. We'd have to look at the .extra file with the same base name as the .dmp file, and parse it (it's key=value pairs), looking for the JavaStackTrace key. If that's found, we could just dump its contents (after mild unescaping: http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter.cpp#59 ) instead of running minidump_stackwalk.

(This may end up overlapping with gbrown's work in bug 823452, but I already had this patch in my queue, so might as well continue for now / we can at least see whether the stacks are any better than those in the logcat)

Resultant stacks are of form: java.lang.NullPointerException at org.mozilla.gecko.GeckoPreferences.onResume(GeckoPreferences.java:106) at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1149) at android.app.Activity.performResume(Activity.java:3823) at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3118) at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3143) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2684) at android.app.ActivityThread.access$2300(ActivityThread.java:125) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2033) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:123) at android.app.ActivityThread.main(ActivityThread.java:4627) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:521) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626) at dalvik.system.NativeStart.main(Native Method)

Wontfixing in favour of the approach used in bug 823452. We can always return to this if we think that the crash reporter's JavaStack field will lend itself to better stacks than those in the logcat (but at this point in time, they look pretty much identical, unless I'm missing something).