Closed
Bug 760415
Opened 12 years ago
Closed 12 years ago
Firefox crashes if locking and unlocking Windows XP while on http://chrome.angrybirds.com/
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
RESOLVED
FIXED
mozilla14
Tracking | Status | |
---|---|---|
firefox13 | + | --- |
firefox14 | + | unaffected |
People
(Reporter: ioana_damy, Assigned: bjacob)
References
Details
(Keywords: crash, reproducible, Whiteboard: webgl-next)
Crash Data
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•12 years ago
|
Severity: normal → major
Reporter | ||
Comment 1•12 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•12 years ago
|
||
It would probably be very useful to bisect when the crash went away (between FF 13 and 14) using archived Nightly builds.
We're trying to track down a regression range now.
Keywords: regressionwindow-wanted,
reproducible
Updated•12 years ago
|
tracking-firefox13:
--- → +
tracking-firefox14:
--- → +
Comment 4•12 years ago
|
||
Will likely end up getting wontfix'd for 13 but this seems likr something to fix for 14 given k9o coming up.
Comment 5•12 years ago
|
||
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•12 years ago
|
status-firefox14:
--- → unaffected
Assignee | ||
Comment 7•12 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•12 years ago
|
Whiteboard: webgl-next
Updated•12 years ago
|
Updated•12 years ago
|
Whiteboard: webgl-next
Assignee | ||
Comment 8•12 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•12 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
Closed: 12 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•12 years ago
|
||
Filed bug 764578 for the remaining issue.
Updated•12 years ago
|
Target Milestone: --- → mozilla14
Updated•9 years ago
|
Keywords: regressionwindow-wanted
Comment 11•9 years 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.
Description
•