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

Status: RESOLVED DUPLICATE of bug 1150693

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Aaron Train [:aaronmt]]

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

java.lang.NullPointerException
	at org.mozilla.gecko.gfx.GeckoLayerClient.syncViewportInfo(GeckoLayerClient.java:691)
	at dalvik.system.NativeStart.run(Native Method)
	at dalvik.system.NativeStart.run(Native Method)

Comment 1

[Kartikaya Gupta (email:[e-mail])]

That's.. not possible? The line in question is this:

https://hg.mozilla.org/mozilla-central/file/6e3ec93efe1d/mobile/android/base/gfx/GeckoLayerClient.java#l691

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.

Comment 2

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

Current crashes are happening on GeckoLayerClient.java line 683 which is:
http://mxr.mozilla.org/mozilla-release/source/mobile/android/base/gfx/GeckoLayerClient.java#683

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

Comment 3

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

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     }

Comment 4

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 5

[Geoff Brown [:gbrown]]

I am landing a brute force avoid-the-NPE patch in bug 982106, to address the test crashes. 

:kats observed in https://bugzilla.mozilla.org/show_bug.cgi?id=982106#c30, "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."

Comment 6

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

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(LayerRenderer.java:339)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.LayerRenderer.access$100(LayerRenderer.java:42)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.LayerRenderer$Frame.<init>(LayerRenderer.java:435)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.LayerRenderer.createFrame(LayerRenderer.java:376)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat org.mozilla.gecko.gfx.GeckoLayerClient.createFrame(GeckoLayerClient.java:736)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat dalvik.system.NativeStart.run(Native Method)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat dalvik.system.NativeStart.run(Native Method)
02-14 06:52:49.614  1575  1724 W GeckoLayerClient: \tat dalvik.system.NativeStart.run(Native Method)

Comment 7

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

Looks like bug 982106 is also avoiding the exception in comment 6 too.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Should be fixed by bug 1150693 and friends.