1123688 - crash in java.lang.NullPointerException: at org.mozilla.gecko.home.TopSitesPanel$CursorLoaderCallbacks.onLoadFinishedAfterTransitions(TopSitesPanel.java)

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

This bug was filed from the Socorro interface and is 
report bp-a9da79e4-64dc-4de1-9e05-f6eae2150116.
=============================================================

java.lang.NullPointerException
	at org.mozilla.gecko.home.TopSitesPanel$CursorLoaderCallbacks.onLoadFinishedAfterTransitions(TopSitesPanel.java:721)
	at org.mozilla.gecko.home.TransitionAwareCursorLoaderCallbacks$OnLoadFinishedRunnable.run(TransitionAwareCursorLoaderCallbacks.java:53)
	at org.mozilla.gecko.animation.TransitionsTracker.runAfterTransitions(TransitionsTracker.java:114)
	at org.mozilla.gecko.home.TransitionAwareCursorLoaderCallbacks.onLoadFinished(TransitionAwareCursorLoaderCallbacks.java:19)
	at android.support.v4.app.LoaderManagerImpl$LoaderInfo.callOnLoadFinished(Unknown Source)
	at android.support.v4.app.LoaderManagerImpl$LoaderInfo.onLoadComplete(Unknown Source)
	at android.support.v4.content.Loader.deliverResult(Unknown Source)
	at org.mozilla.gecko.home.SimpleCursorLoader.deliverResult(SimpleCursorLoader.java:71)
	at org.mozilla.gecko.home.SimpleCursorLoader.deliverResult(SimpleCursorLoader.java:26)
	at android.support.v4.content.AsyncTaskLoader$LoadTask.onPostExecute(Unknown Source)
	at android.support.v4.content.ModernAsyncTask.access$500(Unknown Source)
	at android.support.v4.content.ModernAsyncTask$InternalHandler.handleMessage(Unknown Source)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:157)
	at android.app.ActivityThread.main(ActivityThread.java:5633)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:515)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:896)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:712)
	at dalvik.system.NativeStart.main(Native Method)

Comment 1

[Aaron Train [:aaronmt]]

Due to bug 1077590?

Comment 2

[Richard Newman [:rnewman]]

Not impossible, I suppose.

That error is that we're being invoked with a null cursor.

STR or a log would be helpful.

Comment 4

[Aaron Train [:aaronmt]]

Snorp says

> I've hit this on nightly several times by clicking the url bar on the awesome screen I believe.

Comment 5

[Richard Newman [:rnewman]]

This should only happen if the profile being fetched is falling back to a stub DB.

snorp, do you see

  GeckoProfile/D    Defaulting to StubBrowserDB.

in the log?

That should *never* occur outside of a web app, because the factory is set in the GeckoApp constructor, which is guaranteed to run before any uses of its profile.

Comment 6

[(not currently active) Ted Mielczarek]

I *think* I've seen this on my HTC One M8 by invoking Nightly by swiping its icon up on the lock screen. In fact I just reproduced it doing something similar, although I can't reproduce it reliably. What I just did:
1) Had an existing tab open.
2) Locked screen
3) Press power, swipe up Nightly icon to unlock directly to Nightly
4) Used "send to other devices" to send the existing tab to my desktop
5) Closed that tab
6) Crash viewing homescreen
https://crash-stats.mozilla.com/report/index/65f29638-87c0-4ed2-ab3e-cd5432150122

Comment 7

[Aaron Train [:aaronmt]]

#1 on 38

Comment 8

[Aaron Train [:aaronmt]]

Comments

Just started it. I didn't even saw a page.

Just opened browser - closed an old re-opened tab and browser crashed...

Not sure - just did a search through the search app. followed a couple of links then hit the address/search bar
 
Third time in 24 hours - hit the address bar to make subsiquent search after using nightly search app and browser crashed...

Crashed after viewing a link in from the Search App. again. Sems to be pretty consistent now - I have had about a dozen crashes in the last couple of days - Time to sort this I think - Do you want me to carry out any tests?

Comment 9

[Aaron Train [:aaronmt]]

Attachment: log.log

I hit this under a new profile on trunk (01/22) on first launch

Comment 10

[Aaron Train [:aaronmt]]

Steps to reproduce

i) With a new profile in Nightly launch Nightly Search
ii) Back out and launch the browser

Crash

Comment 11

[Aaron Train [:aaronmt]]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3d846527576f&tochange=63006936ab99

Comment 12

[Richard Newman [:rnewman]]

Yup, failure is that the search activity is creating the profile, but it's creating it with a StubBrowserDB.

Comment 14

[Richard Newman [:rnewman]]

Attachment: Set BrowserDB factory in application startup, not only for GeckoApp subclasses.

The issue: only by launching GeckoApp (or a subclass) did we specify what kind of DB we wanted. If we don't specify, we get a StubBrowserDB.

The search activity is not a GeckoApp, but it does implicitly access a profile.

After it got a profile, if you launched the browser you'd get the GeckoProfile instance from the profile cache, which would have a StubBrowserDB. StubBrowserDB deliberately returns null for some queries -- such as getTopSites. That causes us to throw here.

The solution I chose: have *GeckoApplication* specify which kind of DB to use, and then have WebappImpl (the only subclass for which we want different behavior) override it.

GeckoView consumers remain unaffected, because they have their own Application class, and so the usual GeckoProfile fallback applies.

This fixes the STR in this bug. I haven't verified webapps yet.

Comment 15

[Richard Newman [:rnewman]]

I verified through inspection in the debugger that webapp profiles still have a StubBrowserDB.

Comment 16

[Richard Newman [:rnewman]]

https://hg.mozilla.org/integration/fx-team/rev/6fc6668a3da6

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6fc6668a3da6