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

Status: RESOLVED FIXED

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

Description

[Aaron Train [:aaronmt]]

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)

Comment 1

[Richard Newman [:rnewman]]

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.

Comment 2

[Cristina Madaras, QA [:CristinaM]]

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.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 4

[Richard Newman [:rnewman]]

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.

Comment 6

[Aaron Train [:aaronmt]]

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)

Comment 7

[Aaron Train [:aaronmt]]

The above was against my Nexus 5 (4.4.4)

Comment 8

[Aaron Train [:aaronmt]]

(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%.

Comment 9

[Aaron Train [:aaronmt]]

Also reproducible on my Galaxy S5 (4.4.4)

Comment 10

[Richard Newman [:rnewman]]

*sigh*

Comment 11

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

filter on [mass-p5]

Comment 12

[David Weir (satdav)]

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

Comment 13

[Richard Newman [:rnewman]]

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

Comment 14

[Richard Newman [:rnewman]]

No crashes on 38 after build 20150113030205 according to crash-stats.

Let's reopen if any appear.

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

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.