The default bug view has changed. See this FAQ.

Firefox crashes if locking and unlocking Windows XP while on http://chrome.angrybirds.com/

RESOLVED FIXED in mozilla14

Status

()

Core
Canvas: WebGL
--
critical
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: Ioana (away), Assigned: bjacob)

Tracking

({crash, reproducible})

13 Branch
mozilla14
x86
Windows XP
crash, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox13+, firefox14+ unaffected)

Details

(Whiteboard: webgl-next, crash signature)

(Reporter)

Description

5 years ago
Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0
BuildID: 20120531155942

https://crash-stats.mozilla.com/report/index/bp-8383cf6b-82e9-474d-ab1d-4a5112120601

STR:
1. Launch Firefox.
2. Load http://chrome.angrybirds.com/ in the browser.
3. Press Win+L to lock Windows.
4. Enter your password and unlock Windows.

Firefox crashes.

On Aurora and Nightly, WebGL is disabled when reproducing the above steps (WebGL Renderer = false in about:support):
Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120531 Firefox/14.0a2 (20120531042008)
Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/15.0 Firefox/15.0a1 (20120531030517)

Graphics details from about:support :
Adapter Description: Intel(R) G41 Express Chipset
Vendor ID: 0x8086
Device ID: 0x2e32
Adapter RAM: Unknown
Adapter Drivers: igxprd32
Driver Version: 6.14.10.5355
Driver Date: 4-22-2011
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) G41 Express Chipset) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)
GPU Accelerated Windows: 1/1 Direct3D 9
(Reporter)

Updated

5 years ago
Severity: normal → major
(Reporter)

Comment 1

5 years ago
On Firefox versions older than 11.0, the behavior is the same as on Aurora and Nightly: WebGL gets disabled when reproducing the STR.

On Firefox 11.0, this issue reproduces intermittently and not very often.

On Firefox 12.0, this issue reproduces intermittently and quite often for me.

On Firefox 13.0, this issue reproduced for me 100% of the time.

Since the issue is intermittent on 11.0, I couldn't find a regression range. If anyone else tries to find it, please make sure you check that WebGL is enabled before reproducing the STR.
(Assignee)

Comment 2

5 years ago
It would probably be very useful to bisect when the crash went away (between FF 13 and 14) using archived Nightly builds.

Updated

5 years ago
Severity: major → critical
Keywords: crash
We're trying to track down a regression range now.
Keywords: regressionwindow-wanted, reproducible

Updated

5 years ago
tracking-firefox13: --- → +
tracking-firefox14: --- → +

Comment 4

5 years ago
Will likely end up getting wontfix'd for 13 but this seems likr something to fix for 14 given k9o coming up.
Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0

Last bad: 21 April - Firefox 14
First good: 22 April - Firefox 14

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7fda4d02d3ca&tochange=990f6542747b

Can reproduce consistently when:
-dragging AngryBirds character and then quickly selecting Win-L

Can't reproduce by simply selecting Win-L when characters are not in motion. (so neither would the crash be reproducible when Windows locks itself)
Seems like there are a few WebGL patches in there that could have fixed this for Firefox 14. Benoit, can you have a look?

Updated

5 years ago
status-firefox14: --- → unaffected
(Assignee)

Comment 7

5 years ago
Yes, indeed, that makes a lot of sense. The un-regression-range from comment 5 shows that it's been fixed by the patches in bug 736481 which indeed fixed exactly this kind of bug.

I should have thought of requesting aurora/beta approval then. Now obviously it's too late for Firefox 13, so we will have to live with this crasher in Firefox 13.

But there is a second bug there, that we should fix: according to comment 0, on Firefox 14+, there is still a bug that causes WebGL to be disabled after this has happened. Now, given comment 5, we know that this stuff is caused by context loss handling, so it's a really important bug to fix (we really want context loss handling to work as well as possible, it's an important aspect of our tech evangelism as we want developers to handle context loss properly).

Will look into this ASAP next week, self-assigning.
Assignee: nobody → bjacob
(Assignee)

Updated

5 years ago
Whiteboard: webgl-next

Updated

5 years ago
Status: NEW → ASSIGNED
Depends on: 736481
Whiteboard: webgl-next

Updated

5 years ago
Whiteboard: webgl-next
(Assignee)

Comment 8

5 years ago
So the problem is that in gfx/angle/src/libEGL/Display.cpp, in Display::createOffscreenSurface, at line 682, we have:

    if (testDeviceLost()) 
    {
        if (!restoreLostDevice())
            return EGL_NO_SURFACE;
    }

and in the circumstances reproducing this bug, testDeviceLost() return true here so we bail out with EGL_NO_SURFACE here.

Need a D3D expert to see if there is anything to do here...
(Assignee)

Comment 9

5 years ago
To be clear, the present bug here is already fixed in Firefox 14+ per se; we're discussing a follow-up bug here. Filing a new bug for that.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Blocks: 764578
Filed bug 764578 for the remaining issue.

Updated

5 years ago
Target Milestone: --- → mozilla14
Keywords: regressionwindow-wanted

Comment 11

a year ago
Hello, 
I have an identical crash problem on

Mozilla/5.0 (Windows NT 5.1; rv:44.0) Gecko/20100101 Firefox/44.0

(except that it is not related to http://chrome.angrybirds.com/ as I never in my life visited this webpage, I don't know what website it is caused by and if at all it is caused by a website and not by something else.) It doesn't crash always, just once every few days, but sometimes more often and it starts to be annoying, that's why I just registered on Bugzilla, it crashed recently yesterday. And also I had the this on many previous versions of Firefox too, I don't remeber exactly for how long it happens already and how many previous versions are affected but I have a few hundreds of crash logs in "about:crashes", of course, not all the crash logs are associated with this problem, I do not know how many of the crash logs refers to this problem. The most current crash log is from 2016-02-02 21:57, the oldest one is from 2014-07-09 14:41. I attach here the 5 most recent crash logs (the first one at 100% refer to the problem). I don't know how about the others. If you need I may attach all the crash logs.

https://crash-stats.mozilla.com/report/index/bp-1582c23b-9793-48aa-9eed-a4a1d2160202
https://crash-stats.mozilla.com/report/index/bp-ff2ab302-8f49-4ad8-a65e-e64d12160202
https://crash-stats.mozilla.com/report/index/bp-82b3b673-7115-4540-bf79-ddb682160202
https://crash-stats.mozilla.com/report/index/bp-01969a03-d345-4546-ae8d-658f02160202
https://crash-stats.mozilla.com/report/index/bp-d7ed8fdf-183c-4123-a0a5-676f52160202

As I see the bug as "RESOLVED FIXED"... but the bug still affects me, so should the bug to be changed to "UNRESOLVED UNFIXED" again? Or should I post this as a new bug? Or maybe it is related to another bug? Can you help me and fix the crash problem? Sorry but as I am a newbie here on Bugzilla, I didn't know where to put my problem, I even thinked about putting this on Mozilla Help Forums first, but as I saw that someone already had the same problem, so to do not mess I decided to attach here. If this is a wrong place please move it to a proper place.

Thanks.
You need to log in before you can comment on or make changes to this bug.