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

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Web Apps (PWAs), defect, P1)

Description

[Flaviu Cos]

This bug was filed from the Socorro interface and is 
report bp-f8325061-ae8f-4f12-9e3a-c4e252140205.
=============================================================

Environment: 
Device: Google Nexus 7 (Android 4.4.2);
Build: Aurora 29.0a2 (2014-02-04);

The crash happen when I tried to install wikipedia webapp.
I could reproduce the crash only once.
Can not reproduce it again.

Stack Trace:
0	libmozalloc.so	mozalloc_abort(char const*)	memory/mozalloc/mozalloc_abort.cpp
1	libxul.so	Java_org_mozilla_gecko_GeckoAppShell_reportJavaCrash	widget/android/AndroidJNI.cpp
2	libmozglue.so	Java_org_mozilla_gecko_GeckoAppShell_reportJavaCrash	mozglue/android/jni-stubs.inc
3	libdvm.so	libdvm.so@0x1dbce	
4	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0x1d3f7c	
5	dalvik-heap (deleted)	dalvik-heap (deleted)@0x1a246	
6	libdvm.so	libdvm.so@0x4e125	
7	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0x1d3f7a	
8	libmozglue.so	Java_org_mozilla_gecko_GeckoAppShell_dispatchMemoryPressure	mozglue/android/jni-stubs.inc
9		@0x688bf9ca	
10	dalvik-mark-stack (deleted)	dalvik-mark-stack (deleted)@0x4a06003	
11	libmozglue.so	Java_org_mozilla_gecko_GeckoAppShell_dispatchMemoryPressure	mozglue/android/jni-stubs.inc
12	libc.so	libc.so@0x49ffe	
13	libc.so	libc.so@0xdcc3	
14	libdvm.so	libdvm.so@0x4fd55	
15	libdvm.so	libdvm.so@0x69bf7	
16	dalvik-zygote (deleted)	dalvik-zygote (deleted)@0x1d34e	
17	libdvm.so	libdvm.so@0x69c1b	
18	core.odex	core.odex@0x1bbf02	
19	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x35242a	
20	dalvik-heap (deleted)	dalvik-heap (deleted)@0x1a246	
21	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x352416	
22	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0x1fcbce	
23	libdvm.so	libdvm.so@0x6be39	
24	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0x1fcbce	
25	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0x4592e	
26	dalvik-heap (deleted)	dalvik-heap (deleted)@0x1a246	
27	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0x1fcbce	
28		@0x683e6ffe	
29	libdvm.so	libdvm.so@0x4fc5b	
30	libdvm.so	libdvm.so@0xaac72	
31	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x352416	
32	libdvm.so	libdvm.so@0x4df93	
33	libdvm.so	libdvm.so@0xaf1ee	
34	libdvm.so	libdvm.so@0xaac72	
35	libdvm.so	libdvm.so@0x4fb11	
36	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0xc8e9c	
37	dalvik-heap (deleted)	dalvik-heap (deleted)@0x1a246	
38	libdvm.so	libdvm.so@0x1dd3e	
39	libdvm.so	libdvm.so@0x26fe2	
40	libdvm.so	libdvm.so@0x2df52	
41	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x351c6e	
42	libdvm.so	libdvm.so@0x2dfa2	
43	dalvik-heap (deleted)	dalvik-heap (deleted)@0x826de	
44	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0x112a9c	
45	libdvm.so	libdvm.so@0x2df52	
46	libdvm.so	libdvm.so@0x2b63a	
47	libdvm.so	libdvm.so@0x2df52	
48	libsqlite.so	libsqlite.so@0x36ffe	
49	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x351c6e	
50	data@[e-mail][e-mail]	data@[e-mail][e-mail]@0x1d4094	
51	libdvm.so	libdvm.so@0x60583	
52	dalvik-LinearAlloc (deleted)	dalvik-LinearAlloc (deleted)@0x351c6e	
53	icudt51l.dat	icudt51l.dat@0x5f8fff	
54	libc.so	libc.so@0x4c2ea	
55	libdvm.so	libdvm.so@0x49d0d	
56	libdvm.so	libdvm.so@0x4952b	
57	libdvm.so	libdvm.so@0x49ceb	
58	libxul.so	_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)	android-ndk/platforms/android-9/arch-arm/usr/include/jni.h
59	libxul.so	mozilla::widget::android::GeckoAppShell::HandleUncaughtException(_jobject*, _jthrowable*)	widget/android/GeneratedJNIWrappers.cpp
60	libxul.so	mozilla::AndroidBridge::HandleUncaughtException(_JNIEnv*)	widget/android/AndroidBridge.h
61	libxul.so	mozilla::widget::android::GeckoLayerClient::SetFirstPaintViewport(float, float, float, float, float, float, float)	widget/android/GeneratedJNIWrappers.cpp
62	libxul.so	mozilla::AndroidBridge::SetFirstPaintViewport(mozilla::gfx::IntPointTyped<mozilla::LayerPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::LayerPixel> const&, mozilla::gfx::RectTyped<mozilla::CSSPixel> const&)	widget/android/AndroidBridge.cpp
63	libxul.so	mozilla::layers::AsyncCompositionManager::TransformScrollableLayer(mozilla::layers::Layer*)	gfx/layers/composite/AsyncCompositionManager.cpp
64	libxul.so	mozilla::layers::AsyncCompositionManager::TransformShadowTree(mozilla::TimeStamp)	gfx/layers/composite/AsyncCompositionManager.cpp
65	libxul.so	mozilla::layers::CompositorParent::CompositeInTransaction()	gfx/layers/ipc/CompositorParent.cpp
66	libxul.so	mozilla::layers::CompositorParent::ResumeComposition()	gfx/layers/ipc/CompositorParent.cpp
67	libxul.so	RunnableMethod<mozilla::ipc::MessageChannel, void (mozilla::ipc::MessageChannel::*)(mozilla::ipc::MessageChannel*, mozilla::ipc::Side), Tuple2<mozilla::ipc::MessageChannel*, mozilla::ipc::Side> >::Run()	ipc/chromium/src/base/tuple.h
68	libxul.so	MessageLoop::RunTask(Task*)	ipc/chromium/src/base/message_loop.cc
69	libxul.so	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&)	ipc/chromium/src/base/message_loop.cc
70	libxul.so	MessageLoop::DoWork()	ipc/chromium/src/base/message_loop.cc
71	libxul.so	base::MessagePumpDefault::Run(base::MessagePump::Delegate*)	ipc/chromium/src/base/message_pump_default.cc
72	libxul.so	MessageLoop::RunInternal()	ipc/chromium/src/base/message_loop.cc
73	libxul.so	MessageLoop::Run()	ipc/chromium/src/base/message_loop.cc
74	libxul.so	base::Thread::ThreadMain()	ipc/chromium/src/base/thread.cc
75	libxul.so	ThreadFunc	ipc/chromium/src/base/platform_thread_posix.cc
76	libc.so	libc.so@0xd22a	
77	libc.so	libc.so@0xd3c2

Comment 1

[Aaron Train [:aaronmt]]

I saw this two days ago; snorp said there's already a bug on file for this. Dupe?

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

Yeah, Jim fixed it but I can't seem to find it.

Comment 3

[(inactive) Jim Chen [:jchen] [:darchons]]

I think that was something else. I've never seen this crash.

Comment 4

[Robert Kaiser]

I just saw this today in Nightly 31, trying to launch a web app, see bp-cbfec914-4786-466b-8348-87b232140321

Comment 5

[Robert Kaiser]

Apparently I get this pretty consistently if I try launching a web app when Nightly is not open. When Nightly is open, web apps are just stuck on the launch screen (with the icon an derived background color).

Comment 6

[u421692]

I can reproduce this everytime on Alcatel One Touch 8008D, on Firefox 29 Beta 4, Aurora and Nightly, when FF is in background and I try to open a webapp from android apps menu.

Also, when I have installed only Firefox Beta, or start FF beta with a clean profile, web-apps fail to start(freeze at split screen). I was only able to reproduce this issue on this device.

From the crash reports, the users are describing the same behaviour(web-apps fail to start and FF crashes): 
https://crash-stats.mozilla.com/report/list?signature=java.lang.NullPointerException%3A+at+org.mozilla.gecko.gfx.GeckoLayerClient.setFirstPaintViewport%28GeckoLayerClient.java%29&product=FennecAndroid&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2014-04-01+12%3A00%3A00&range_value=1#tab-reports

I think this issue should be P1 priority since an important feature is not working.

Comment 7

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

Likely Tabs.getSelectedTab() is returning null when we call it in setFirstPaintViewport, and then we try calling things on it. We can add null guards but I'd like to understand why getSelectedTab() returns null in the web runtime environment but not in the normal runtime environment. Are there any Tab objects created in the web runtime environment? Or is the tab not the selected tab? Is it just delayed?

Comment 8

[Myk Melez [:myk] [@mykmelez]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> Likely Tabs.getSelectedTab() is returning null when we call it in
> setFirstPaintViewport, and then we try calling things on it. We can add null
> guards but I'd like to understand why getSelectedTab() returns null in the
> web runtime environment but not in the normal runtime environment. Are there
> any Tab objects created in the web runtime environment? Or is the tab not
> the selected tab? Is it just delayed?

Fennec loads the initial Tab in GeckoApp.loadStartupTab:

http://hg.mozilla.org/mozilla-central/annotate/d8e8f13bd4ae/mobile/android/base/GeckoApp.java#l1430

But webapp/WebappImpl, which extends GeckoApp, overrides that method with one that doesn't load a tab:

http://hg.mozilla.org/mozilla-central/annotate/ccd91b78561f/mobile/android/base/webapp/WebappImpl.java#l185

Instead, webapp/WebappImpl.onCreate calls GeckoApp.onCreate and then calls GeckoAppShell.sendEventToGecko(GeckoEvent.createBroadcastEvent("Webapps:Load", …)), which browser.js's BrowserApp observes, passing it to _loadWebapp, which calls _initRuntime, which loads WebappRT.js (synchronously), which waits for DOMApplicationRegistry.registryReady (asynchronously) before calling a callback that finally calls BrowserApp.addTab (which itself does a bunch of work before sending "Tab:Added" to Java to finally create the Java Tab object):

http://hg.mozilla.org/mozilla-central/annotate/1417d180a1d8/mobile/android/chrome/content/browser.js#l944

So my guess is that the runtime takes too long to create the initial Tab object, and it should be creating it sooner, perhaps as soon as loadStartupTab, even if it has to load an empty page into the tab initially and then set its URL to the proper launch URL once it's ready to do so.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: load initial tab in WebappImpl:loadStartupTab

If my guess is right, then this patch should fix the problem, although I'm unfamiliar with setFirstPaintViewport, and I can't reproduce the problem on my local test devices, so I can't say for sure.

The patch loads about:blank in WebappImpl:loadStartupTab to ensure there's a tab available for webapps just as soon as there's one available in Fennec.  It also suppresses the titlebar when the location of a tab changes to about:blank so that the titlebar doesn't appear for this initial tab.

One consequence of this simple fix is that webapps load two tabs: this initial one and the second one into which they load the webapp content.  I'm not sure if there are any consequences for that.  If so, then presumably we could switch to reusing the initial tab to load the webapp.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

(In reply to Robert Kaiser (:[e-mail]) from comment #5)
> Apparently I get this pretty consistently if I try launching a web app when
> Nightly is not open. When Nightly is open, web apps are just stuck on the
> launch screen (with the icon an derived background color).

(In reply to Mihai Pop from comment #6)
> Also, when I have installed only Firefox Beta, or start FF beta with a clean
> profile, web-apps fail to start(freeze at split screen). I was only able to
> reproduce this issue on this device.

I think this is a different problem (or possibly two different problems).

If the apps were originally installed as legacy shortcuts, then it could be bug 982557, which was uplifted to Beta last Friday, March 28, so it isn't in the latest beta available from Google Play.

Otherwise, bug 989294 describes a similar hang on launch that might be related.

Comment 11

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

Comment on attachment 8400194 [details] [diff] [review]
patch v1: load initial tab in WebappImpl:loadStartupTab

Review of attachment 8400194 [details] [diff] [review]:
-----------------------------------------------------------------

I don't know this code beyond what you said above, but sure, I'll f+ this.

Comment 12

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

Comment on attachment 8400194 [details] [diff] [review]
patch v1: load initial tab in WebappImpl:loadStartupTab

This seem safe enough for uplifting.

Can you file a followup to remove or reuse the extra tab?  We should fix that at some point. It does use up memory.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

(In reply to Mark Finkle (:mfinkle) from comment #12)
> Can you file a followup to remove or reuse the extra tab?  We should fix
> that at some point. It does use up memory.

You bet!  I filed it as bug 990959.

Comment 14

[Myk Melez [:myk] [@mykmelez]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8ef4a95c868c

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/8ef4a95c868c

Comment 16

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 8400194 [details] [diff] [review]
patch v1: load initial tab in WebappImpl:loadStartupTab

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
  Bug 934756.

User impact if declined: 
  Some users won't be able to run webapps, which will crash on launch.

Testing completed (on m-c, etc.): 
  The fix landed on Central earlier today.

Risk to taking this patch (and alternatives if risky): 
  It's the lowest-risk fix for the bug and is fairly low-risk.

String or IDL/UUID changes made by this patch:
  None.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/2771311502b5
https://hg.mozilla.org/releases/mozilla-beta/rev/d75416f21916

Comment 18

[u421692]

Verified as fixed on Alcatel One Touch 8008D(Android 4.1.2), on Nighlty 31.0a1(2014-04-14), on Aurora 30.0a2(2014-04-14), and Firefox 29 Beta 6.