Closed Bug 975566 Opened 9 years ago Closed 8 years ago

crash in java.lang.NullPointerException: at org.mozilla.gecko.gfx.GeckoLayerClient.syncViewportInfo(


(Firefox for Android Graveyard :: Toolbar, defect)

30 Branch
Not set


(firefox29 affected, firefox30 affected)

Tracking Status
firefox29 --- affected
firefox30 --- affected


(Reporter: aaronmt, Unassigned)



(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-d1214378-f46f-45b0-9773-d6cae2140220.

	at org.mozilla.gecko.gfx.GeckoLayerClient.syncViewportInfo(
	at Method)
	at Method)
That's.. not possible? The line in question is this:

The only thing that can be null there is mDrawTimingQueue which is created in the constructor and never nulled out, so there's no way it can be null.
See Also: → 982106
Current crashes are happening on line 683 which is:

683 mRootLayer.setPositionAndResolution(
684             Math.round(x + mCurrentViewTransform.offsetX),
685             Math.round(y + mCurrentViewTransform.offsetY),
686             Math.round(x + width + mCurrentViewTransform.offsetX),
687             Math.round(y + height + mCurrentViewTransform.offsetY),
688             resolution);

I don't know if it's really line 683 (mRootLayer is null) or any of the params (mCurrentViewTransform is null).
Should we be checking for mGeckoIsReady in syncViewportInfo ? I notice we do that in a getter for the root:

196     Layer getRoot() {
197         return mGeckoIsReady ? mRootLayer : null;
198     }
I can't be mCurrentViewTransform that's null otherwise it would crash a few lines up from there. It must be mRootLayer that's null. If these are startup crashes then yes, it's likely that mGeckoIsReady is false and we shouldn't even be getting calls to syncViewportInfo. Maybe something changed in the compositor and that's starting to tickle this bug. Guarding that setPositionAndResolution call with a mRootLayer != null check should fix it then.
I am landing a brute force avoid-the-NPE patch in bug 982106, to address the test crashes. 

:kats observed in, "We should leave bug 975566 open and repurpose to it investigate the root cause. Something is causing the compositor to start running and compositing before Java gets word that Gecko is even up and running."
In several of the captured logs, I see this exception once or twice before the syncViewportInfo crash:

02-14 06:52:49.614  1575  1724 W GeckoLayerClient: java.lang.IllegalStateException
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.LayerRenderer.createContext(
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.LayerRenderer.access$100(
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.LayerRenderer$Frame.<init>(
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.LayerRenderer.createFrame(
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.GeckoLayerClient.createFrame(
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat Method)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat Method)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat Method)
Looks like bug 982106 is also avoiding the exception in comment 6 too.
Should be fixed by bug 1150693 and friends.
Closed: 8 years ago
Resolution: --- → DUPLICATE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.