This bug was filed from the Socorro interface and is report bp-6a10582d-38f3-4b3d-abd4-f4dc42141003. ============================================================= java.lang.NullPointerException at org.mozilla.gecko.db.BrowserDB.getCount(BrowserDB.java:236) at org.mozilla.gecko.BrowserApp.handleMessage(BrowserApp.java:1481) at org.mozilla.gecko.EventDispatcher.dispatchEvent(EventDispatcher.java:168) at org.mozilla.gecko.GeckoAppShell.handleGeckoMessage(GeckoAppShell.java:2348) at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method) at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method) at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method) at org.mozilla.gecko.GeckoAppShell.runGecko(GeckoAppShell.java:369) at org.mozilla.gecko.GeckoThread.run(GeckoThread.java:190)

This is a use-before-init of BrowserDB. The only use of getCount is in the handler for Telemetry:Gather. That means we're somehow handling a telemetry request prior to having called BrowserDB.initialize from GeckoApp.initialize. This is an HTC One M7, which is fast, but not fast enough that Gecko should init before GeckoApp. My guess, then, is: for some reason, we started GeckoApp, which kicked off a Gecko thread, but the window never got focus, so we never called GeckoApp.initialize. Wait long enough after that happens, and we'll try to gather telemetry, which will cause exactly this problem. It's not visible from any other cause (e.g., a BrowserDB query), because we don't attempt to show data until we're displaying the activity, which of course will trigger init. I'm not super concerned about this unless we see another report. Let's see if Wes or Brian have alternative hypotheses.

I am able to reproduce this crash on Nightly (2014-10-10) using Nexus 4 (Android 4.4.4). Steps: 1. Launch Fennec with a clean profile -> Onboarding screen is displayed; 2. Wait a few minutes -> Fennec crashes.

(In reply to Cristina Madaras, QA [:CristinaM] from comment #2) > I am able to reproduce this crash on Nightly (2014-10-10) using Nexus 4 > (Android 4.4.4). > Steps: > 1. Launch Fennec with a clean profile -> Onboarding screen is displayed; > 2. Wait a few minutes -> Fennec crashes. Do you have "Don't keep activities" enabled? I'm just wondering how the DB wouldn't get initialized while the Onboarding screen is visible. If GeckoApp was killed, that might do it.

It's not that the DB isn't initialized, it's that GeckoProfile doesn't know which profile is in use yet. GeckoProfile.get() is returning null, so we're not even getting a handle on the DB.

I was commenting in the above bug. I am hitting this repeatedly on Nightly. STR: new profile, launch Nightly, check back for a crash in a minute or two 10-10 11:24:40.228 D/GeckoHealthRec(26504): Finishing init. 10-10 11:24:40.238 D/GeckoHealthRec(26504): Checking for orphan session. 10-10 11:24:44.548 D/GeckoHardwareUtils(26504): HardwareUtils already inited. 10-10 11:26:39.558 I/GeckoWebappsUpdateTimer(26504): periodic check for webapp updates 10-10 11:26:39.558 D/GeckoWebappManager(26504): checkForUpdates 10-10 11:26:39.558 D/GeckoWebapps(26504): getAll 10-10 11:27:40.168 E/GeckoAppShell(26504): >>> REPORTING UNCAUGHT EXCEPTION FROM THREAD 1222 ("Gecko") 10-10 11:27:40.168 E/GeckoAppShell(26504): java.lang.NullPointerException 10-10 11:27:40.168 E/GeckoAppShell(26504): at org.mozilla.gecko.db.BrowserDB.getCount(BrowserDB.java:237)

The above was against my Nexus 5 (4.4.4)

(In reply to Mark Finkle (:mfinkle) from comment #3) > (In reply to Cristina Madaras, QA [:CristinaM] from comment #2) > > I am able to reproduce this crash on Nightly (2014-10-10) using Nexus 4 > > (Android 4.4.4). > > Steps: > > 1. Launch Fennec with a clean profile -> Onboarding screen is displayed; > > 2. Wait a few minutes -> Fennec crashes. > > Do you have "Don't keep activities" enabled? I'm just wondering how the DB > wouldn't get initialized while the Onboarding screen is visible. If GeckoApp > was killed, that might do it. I don't. I let my device idle on the start pane screen for a minute, crashes 100%.

Also reproducible on my Galaxy S5 (4.4.4)

*sigh*

filter on [mass-p5]

Can confirm this on 37 happened twice when opened nighly for me

This might be resolved by Bug 1077590; let's wait and see on Nightly.

No crashes on 38 after build 20150113030205 according to crash-stats. Let's reopen if any appear.

The fix for this bug is some rather invasive changes. Given the shortened 37 cycle and the scope of the fix letting this ride the trains.