This is currently our #1 top crash on Fx15. It looks like a dialog is being handled on a our background thread, here is the stack: java.lang.IllegalStateException: Hardware acceleration can only be used with a single UI thread. Original thread: Thread[main,5,main] Current thread: Thread[GeckoBackgroundThread,5,main] at android.view.HardwareRenderer$GlRenderer.checkCurrent(HardwareRenderer.java:1284) at android.view.HardwareRenderer$Gl20Renderer.safelyRun(HardwareRenderer.java:1482) at android.view.HardwareRenderer$Gl20Renderer.destroyHardwareResources(HardwareRenderer.java:1506) at android.view.ViewRootImpl.destroyHardwareRenderer(ViewRootImpl.java:4012) at android.view.ViewRootImpl.die(ViewRootImpl.java:3946) at android.view.WindowManagerImpl.removeViewLocked(WindowManagerImpl.java:402) at android.view.WindowManagerImpl.removeView(WindowManagerImpl.java:350) at android.view.WindowManagerImpl$CompatModeWrapper.removeView(WindowManagerImpl.java:160) at android.app.Dialog.dismissDialog(Dialog.java:319) at android.app.Dialog$1.run(Dialog.java:119) at android.os.Handler.handleCallback(Handler.java:615) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:137) at org.mozilla.gecko.GeckoBackgroundThread.run(GeckoBackgroundThread.java:31) more reports can be found here: https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-09-04&signature=java.lang.IllegalStateException%3A%20Hardware%20acceleration%20can%20only%20be%20used%20with%20a%20single%20UI%20thread.%20Original%20thread%3A%20Thread%5Bmain%2C5%2Cmain%5D&version=FennecAndroid%3A15.0
also note that this is a start up crash
Let's reopen it for the remaining crashes. Indeed, it's #8 top crasher in 16.0.
Scoobidiver - are there any correlations to specific Android versions, devices, or kernels? Brad - let us know if there's anything besides an initial qa investigation with affected URLs that you may need.
(In reply to Alex Keybl [:akeybl] from comment #4) > Scoobidiver - are there any correlations to specific Android versions, > devices, or kernels? It's currently a pure JB crash so it seems bug 769894 has fixed crashes on ICS. Those kinds of startup crashes spike after each release.
49 about:home 3 about:blank 1 https://www.google.com/search?q=http%3A%2F%2Fyfrog.com%2Fb9dsc09704yj&ie=utf-8&o 1 http://www.kickstarter.com/projects/freedompop/freedom-sleeve-turn-your-ipod-int 1 http://oaklawn.patch.com/ 1 http://www.mobilegiveaway.mobi/health/?sid=s-us3-ad2-Century%20Link-2861-Generic 1 https://accounts.google.com/ 1 http://www.google.com/search?mmns=0&redir_esc=&redir_esc=&hl=en&client=tablet-an 1 https://www.google.com/search?q=ollie+williams&ie=utf-8&oe=utf-8&aq=t&rls=org.mo
I haven't been able to reproduce this; Nexus 7/Galaxy Nexus.
Devices: Rockchip U30GT-H Samsung GT-P1000 Motorola Xoom 49 Asus Transformer Prime TF201 43 ASUS Transformer Pad TF300T 13 Samsung Galaxy Nexus 9 Samsung Nexus S 5 Asus Nexus 7 2 Acer A500 2 Samsung Nexus S 4G 1 Samsung GT-N7100 1 Motorola MZ601 1 ASUS Transformer Pad TF300TG 1 Amazon Kindle Fire 1 Samsung GT-I9000B 1 Samsung GT-I9100
why are we tracking this? it is the #12 crash on 16, #72 on 17 and doesn't exist on 18 or 19.
This is at #74 on the topcrasher list with only 20 crashes on 17.0b1 so untracking.
(In reply to Brad Lassey [:blassey] from comment #9) > why are we tracking this? it is the #12 crash on 16, #72 on 17 and doesn't > exist on 18 or 19. This startup crash spikes after each release, but doesn't spike in other channels, so it will be again a #10 top crasher in 17.0.
(In reply to Scoobidiver from comment #11) > (In reply to Brad Lassey [:blassey] from comment #9) > > why are we tracking this? it is the #12 crash on 16, #72 on 17 and doesn't > > exist on 18 or 19. > This startup crash spikes after each release, but doesn't spike in other > channels, so it will be again a #10 top crasher in 17.0. Scoobidiver, looking at the link in comment 0 there's a spike on 15.0 release but not 15.0.1, 16.0, or 16.0.1 -- is there evidence somewhere I'm not seeing that this is going to spike for 17's release?
(In reply to Lukas Blakk [:lsblakk] from comment #12) > Scoobidiver, looking at the link in comment 0 there's a spike on 15.0 > release but not 15.0.1, 16.0, or 16.0.1 -- is there evidence somewhere I'm > not seeing that this is going to spike for 17's release? The link in comment 0 doesn't take into account crashes after Sept 4. Use this link instead: https://crash-stats.mozilla.com/report/list?signature=java.lang.IllegalStateException%3A%20Hardware%20acceleration%20can%20only%20be%20used%20with%20a%20single%20UI%20thread.%20Original%20thread%3A%20Thread[main%2C5%2Cmain%5D
If we think this is a device/OS-specific startup crash that users are seeing if we've resolved after each release, there may be value to continue investigating. Otherwise, a spike only after release isn't worth devoting a ton of resources to (and may have something to do with the update itself?). Brad - what do you think?
(I understand this is JB-specific, so what I really meant to ask is if we think this is device-specific and persistent)
(In reply to Alex Keybl [:akeybl] from comment #14) > If we think this is a device/OS-specific startup crash that users are seeing > if we've resolved after each release, there may be value to continue It happens on many devices with any GPU. Note that it was higher in 15.0.1 and has been partially fixed in 16.0.1 and above by bug 769894.
Indeed, this has 4 times less crash volume on 16.0.1 compared to 15.0. Will wait for Brad to make the call on questions in comment 14.
Does assigning this to Kats mean a fix is being investigated here for Beta? We have a couple more weeks of Beta to consider something for uplift.
Created attachment 674116 [details] [diff] [review] Patch After looking at all the Dialog instances we create, I found exactly one that is created on a non-UI thread. (Note that Dialog objects must be created on the UI thread so that the Handler object they hold on to is also for the UI thread). Attached patch moves the creation into the main UI thread, but I haven't tested the patch other than making sure it compiles and pushing it to try.  :gcp, perhaps you can provide STR? I'm not sure under exactly what conditions this code runs. That would allow us to verify that the patch fixes the problem.  https://tbpl.mozilla.org/?tree=Try&rev=d57bb536a439 Also pre-emptively requesting approval for aurora and beta since we're on a rushed timeline and I'm fairly sure this is the right dialog to be tinkering with. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 746365, I think User impact if declined: startup crash under some circumstances when profile migrator runs Testing completed (on m-c, etc.): none Risk to taking this patch (and alternatives if risky): unsure, perhaps gcp can provide more info String or UUID changes made by this patch: none
STR: 1) Copy a places.sqlite from a desktop profile to your mobile profile dir. 2) Remove shared_prefs/ProfileMigrator.xml in your profile. 3) Quit and relaunch Fennec.
Comment on attachment 674116 [details] [diff] [review] Patch Review of attachment 674116 [details] [diff] [review]: ----------------------------------------------------------------- Looks ok to me. ::: mobile/android/base/GeckoApp.java @@ +2345,5 @@ > + // create it in startCallback and still find a reference to it > + // in stopCallback. (We must create it on the UI thread to fix > + // bug 788216). Note that synchronization is not a problem here > + // since it is only ever touched on the UI thread. > + final SetupScreen setupScreenHolder = new SetupScreen; So you need an array here because this must both be final to go into the Runnable, but not final in the sense that you need to change the contents. Neat.
Actually, alternate STR: Uninstall Fennec. Install Fennec. Run. I'm pretty sure that's the STR that we're seeing here; on a fresh profile we need to run the code once to mark that there's nothing to migrate. I was wondering how this code could be an issue on Jelly Bean given that XUL Fennec was deprecated by the time that became available, and especially given that it only runs once and the check to see if it has ran is before the bug. But that's exactly the problem: it needs to run once for *every* user, not just the ones that actually have something to migrate.
(In reply to Gian-Carlo Pascutto (:gcp) from comment #20) > STR: > > 1) Copy a places.sqlite from a desktop profile to your mobile profile dir. > 2) Remove shared_prefs/ProfileMigrator.xml in your profile. > 3) Quit and relaunch Fennec. I was able to repro the crash on a Nightly build using these STR. (Crash report ID at https://crash-stats.mozilla.com/report/index/bp-38c00446-2e13-4bfe-85f3-ff4002121023). The crash occurs once and then does not re-occur when starting Fennec again. This makes sense from the code because the crash happens at the end of the profile migration, so the next time you start up, profile migration is done and doesn't run again. I installed the build from my try push in comment #19 and verified that the crash does not happen with the same STR on that build.
Comment on attachment 674116 [details] [diff] [review] Patch I'm happy with one r+ since I've verified that the fix works. https://hg.mozilla.org/integration/mozilla-inbound/rev/df63d31cb673
"Risk to taking this patch (and alternatives if risky): unsure, perhaps gcp can provide more info" Gian-Carlo - can you respond to this? We want to take this, and we still have time to backout if it goes into Beta 4 but please give examples of what regressions might result from this.
No real risk here, we're moving an operation from the wrong thread to the correct thread. The patch has been tested and verified to work. We want this.
Verified fixed by crash stats.