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@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@0x1d3f7c 5 dalvik-heap (deleted) dalvik-heap (deleted)@0x1a246 6 libdvm.so libdvm.so@0x4e125 7 data@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@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@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@0x1fcbce 23 libdvm.so libdvm.so@0x6be39 24 data@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@0x1fcbce 25 data@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@0x4592e 26 dalvik-heap (deleted) dalvik-heap (deleted)@0x1a246 27 data@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@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@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@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@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@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@app@org.mozilla.fennec_aurora-1.apk@classes.dex data@app@org.mozilla.fennec_aurora-1.apk@classes.dex@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

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

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

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

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

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

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.

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?

(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.

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.

(In reply to Robert Kaiser (:kairo@mozilla.com) 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 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 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.

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

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

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.