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

RESOLVED FIXED

Status

()

Firefox for Android
Data Providers
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: aaronmt, Assigned: rnewman)

Tracking

({crash, reproducible})

35 Branch
All
Android
crash, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

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

Details

(crash signature)

(Reporter)

Description

3 years ago
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)
(Assignee)

Comment 1

3 years ago
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.
(Assignee)

Comment 4

3 years ago
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.
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1078303
(Reporter)

Comment 6

3 years ago
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: --- → ?
status-firefox35: --- → affected
Keywords: reproducible
(Reporter)

Comment 7

3 years ago
The above was against my Nexus 5 (4.4.4)
(Reporter)

Comment 8

3 years ago
(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%.
(Reporter)

Comment 9

3 years ago
Also reproducible on my Galaxy S5 (4.4.4)
(Assignee)

Updated

3 years ago
See Also: → bug 1081768
(Reporter)

Updated

3 years ago
Blocks: 1042809

Updated

3 years ago
tracking-fennec: ? → +
status-firefox36: --- → affected
(Assignee)

Comment 10

3 years ago
*sigh*
Assignee: nobody → rnewman
Status: NEW → ASSIGNED
filter on [mass-p5]
Priority: -- → P5
(Assignee)

Updated

3 years ago
Priority: P5 → --
(Assignee)

Updated

3 years ago
Depends on: 1085591

Comment 12

3 years ago
Can confirm this on 37 happened twice when opened nighly for me
status-firefox37: --- → affected
(Assignee)

Comment 13

3 years ago
This might be resolved by Bug 1077590; let's wait and see on Nightly.
(Assignee)

Comment 14

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

Let's reopen if any appear.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox38: --- → fixed
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.
status-firefox35: affected → wontfix
status-firefox36: affected → wontfix
status-firefox37: affected → wontfix
You need to log in before you can comment on or make changes to this bug.