692185 - Java crashes are not showing up in App Notes for Fennec Java Crashes

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Example of Java information not in the App Notes any more:

https://crash-stats.mozilla.com/report/index/5847e31e-6a11-4444-8799-ca2622111003

Range for is located : https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2011-10-04&signature=__libc_android_abort%20|%20Java_org_mozilla_gecko_GeckoAppShell_reportJavaCrash&version=Fennec%3A7.0.1

Example of crash that does have Java report in it :
https://crash-stats.mozilla.com/report/index/7df304c2-2d35-4f15-91ea-1b3a32110809
In bug 686973

Comment 1

[Robert Helmer [:rhelmer]]

(In reply to Naoki Hirata :nhirata from comment #0)
> Example of Java information not in the App Notes any more:
> 
> https://crash-stats.mozilla.com/report/index/5847e31e-6a11-4444-8799-
> ca2622111003

Took a quick peek at the raw data, the notes field contains:

"Notes": "java.lang.RuntimeException: Unable to pause activity {org.mozilla.fennec/org.mozilla.fennec.App}: java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@40757dd0\r\n\tat android.app.ActivityThread.performPauseActivity(ActivityThread.java:2358)\r\n\tat android.app.ActivityThread.performPauseActivity(ActivityThread.java:2315)\r\n\tat android.app.ActivityThread.handlePauseActivity(ActivityThread.java:2295)\r\n\tat android.app.ActivityThread.access$1700(ActivityThread.java:117)\r\n\tat android.app.ActivityThread$H.handleMessage(ActivityThread.java:942)\r\n\tat android.os.Handler.dispatchMessage(Handler.java:99)\r\n\tat android.os.Looper.loop(Looper.java:123)\r\n\tat org.mozilla.gecko.GeckoApp$3.run(GeckoApp.java:197)\r\n\tat android.os.Handler.handleCallback(Handler.java:587)\r\n\tat android.os.Handler.dispatchMessage(Handler.java:92)\r\n\tat android.os.Looper.loop(Looper.java:123)\r\n\tat android.app.ActivityThread.main(ActivityThread.java:3687)\r\n\tat java.lang.reflect.Method.invokeNative(Native Method)\r\n\tat java.lang.reflect.Method.invoke(Method.java:507)\r\n\tat com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:842)\r\n\tat com.android.internal.os.ZygoteInit.main(ZygoteInit.java:600)\r\n\tat dalvik.system.NativeStart.main(Native Method)\r\nCaused by: java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@40757dd0\r\n\tat android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java:610)\r\n\tat android.app.ContextImpl.unregisterReceiver(ContextImpl.java:919)\r\n\tat android.content.ContextWrapper.unregisterReceiver(ContextWrapper.java:331)\r\n\tat org.mozilla.gecko.GeckoApp.onPause(GeckoApp.java:349)\r\n\tat android.app.Activity.performPause(Activity.java:3851)\r\n\tat android.app.Instrumentation.callActivityOnPause(Instrumentation.java:1191)\r\n\tat android.app.ActivityThread.performPauseActivity(ActivityThread.java:2345)\r\n\t... 16 more\r\n"

Also, I notice this addon is installed: "[e-mail]:1.4.2"

Comment 2

[Robert Kaiser]

So this is a generic Socorro bug in that we don't show all app notes?

Comment 3

[Robert Helmer [:rhelmer]]

(In reply to Robert Kaiser (:[e-mail]) from comment #2)
> So this is a generic Socorro bug in that we don't show all app notes?

Looks like the problem is that this field is restricted to 1000 characters:
https://github.com/mozilla/socorro/blob/v2.2.4/socorro/processor/processor.py#L769

Returning None if it goes over 1k chars seems wrong to me, we should probably truncate it or at least put a message in there that it's too long (preferably the former).

Comment 4

[K Lars Lohn [:lars] [:klohn]]

that code in question truncates a string to 1000 characters. It only assigns None (NULL in the database) if the key "Notes" is missing from the json.  

If you click on the "failed" report link in Comment #0, the original problematic crash report does have information in the "AppNotes" field: "HTC ADR6350\nverizon_wwe/htc_vivow/vivow:2.3.4/GRJ22/120826.3:user/release-keys".  This is precisely what is in the raw json for that report.  

Rhelmer, in comment #1, I believe that you picked up the wrong raw json file. You quoted the raw data from the example that worked, not the example that "failed".  Here's the "failed" json:

{"InstallTime": "1317428617", 
 "Android_Fingerprint": "verizon_wwe/htc_vivow/vivow:2.3.4/GRJ22/120826.3:user/release-keys", 
 "Theme": "classic/1.0", 
 "Version": "7.0.1", 
 "Android_Hardware": "vivow", 
 "Vendor": "Mozilla", 
 "EMCheckCompatibility": "true", 
 "Android_Device": "vivow", 
 "Android_CPU_ABI2": "armeabi", 
 "ReleaseChannel": "release", 
 "submitted_timestamp": "2011-10-03T23:28:01.081956", 
 "Android_CPU_ABI": "armeabi-v7a", 
 "timestamp": 1317709681.082077, 
 "Notes": "HTC ADR6350\nverizon_wwe/htc_vivow/vivow:2.3.4/GRJ22/120826.3:user/release-keys", 
 "Android_Display": "GRJ22", 
 "Android_Manufacturer": "HTC", 
 "FramePoisonSize": "4096", 
 "Android_Brand": "verizon_wwe", 
 "StartupTime": "1317709159", 
 "Min_ARM_Version": "7", 
 "Add-ons": "", 
 "BuildID":  "20110928142707", 
 "Android_Model": "ADR6350", 
 "ProductName": "Fennec", 
 "legacy_processing": 0, 
 "Android_Version": "10 (REL)", 
 "Android_Board": "vivow"}

So Socorro reported exactly what was in the "failed" json Notes field.  If there is Java information missing from this field, it wasn't Socorro that lost it.  I suggest that this is a breakpad problem not a Socorro problem.

Comment 5

[Laura Thomson :laura]

Ted, can you take a look please?

Comment 6

[(not currently active) Ted Mielczarek]

I'm not intimately familiar with the Java code here. I'd punt this to blassey or someone, but I'm guessing they don't have the cycles to deal with it either.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch for mozilla-central

This may or may not fix the problem.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch for projects/birch

Same patch, but applied to the birch branch.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Comment on attachment 569488 [details] [diff] [review]
Patch for mozilla-central

Can't hurt, and I'm willing to see if this fixes the problem over the next few days

Comment 10

[Ed Morley [:emorley]]

Comment on attachment 569488 [details] [diff] [review]
Patch for mozilla-central

In my queue, which is going via try then onto inbound:
https://tbpl.mozilla.org/?tree=Try&rev=d3d2522ed095

Leaving checkin-needed for the birch patch.

Comment 11

[Ed Morley [:emorley]]

m-c patch: https://hg.mozilla.org/integration/mozilla-inbound/rev/0cb7f5ce5cef

On merge, leave open for birch part.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Merged into birch from m-c via http://hg.mozilla.org/projects/birch/rev/8389b4a42ccd

Comment 13

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/0cb7f5ce5cef

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Ed Morley [:edmorley] from comment #11)
> m-c patch:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/0cb7f5ce5cef
> 
> On merge, leave open for birch part.

we do periodic merges to birch from mozilla-central, no need to land separately

Comment 15

[Ed Morley [:emorley]]

(In reply to Brad Lassey [:blassey] from comment #14)
> we do periodic merges to birch from mozilla-central, no need to land
> separately

I was inferring from the other attached patch, I didn't look at it's contents.

Comment 16

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Reopening due to bug 700192 showing incomplete within Socorro.

https://crash-stats.mozilla.com/report/index/cb833641-716d-400f-87ea-65a0e2111105

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Attachment: Another patch for m-c

Uhh.. apparently there's two places in the code that report the top-level exceptions, and I only added the flush call on one of them. Oops. This patch adds it to the other place as well.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

Checkin needed for attachment #573184 [details] [diff] [review].

Comment 19

[Ed Morley [:emorley]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a2cb8a2bcff8

Comment 20

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/a2cb8a2bcff8

Comment 21

[Alex Keybl [:akeybl]]

Sheila/Marcia - is this enough of a hindrance to the crash-kill team that we should pursue a fix in FF10?