Closed Bug 1077858 Opened 10 years ago Closed 10 years ago

crash in java.lang.NullPointerException: at org.mozilla.gecko.db.BrowserDB.getCount(BrowserDB.java)

Categories

(Firefox for Android Graveyard :: Data Providers, defect)

35 Branch
All
Android
defect
Not set
critical

Tracking

(firefox35 wontfix, firefox36 wontfix, firefox37 wontfix, firefox38 fixed, fennec+)

RESOLVED FIXED
Tracking Status
firefox35 --- wontfix
firefox36 --- wontfix
firefox37 --- wontfix
firefox38 --- fixed
fennec + ---

People

(Reporter: aaronmt, Assigned: rnewman)

References

Details

(Keywords: crash, reproducible)

Crash Data

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)
tracking-fennec: --- → ?
Keywords: reproducible
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)
Blocks: firstrun
tracking-fennec: ? → +
*sigh*
Assignee: nobody → rnewman
Status: NEW → ASSIGNED
filter on [mass-p5]
Priority: -- → P5
Priority: P5 → --
Depends on: 1085591
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.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Depends on: 1077590
No longer depends on: 1085591
Resolution: --- → FIXED
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.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.