809065 - Fennec Java crashes need to make use of the JavaStack

Status: RESOLVED WONTFIX

(Testing :: General, defect)

Description

[Phil Ringnalda (:philor)]

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)

Comment 1

[(not currently active) Ted Mielczarek]

"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.

Comment 2

[Ed Morley [:emorley]]

(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)

Comment 3

[Ed Morley [:emorley]]

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)

Comment 4

[Ed Morley [:emorley]]

https://tbpl.mozilla.org/?tree=Try&rev=df8587cb7ddd

Comment 5

[Ed Morley [:emorley]]

Attachment: WIP

Comment 6

[Ed Morley [:emorley]]

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).