Closed
Bug 713369
Opened 13 years ago
Closed 12 years ago
Between 30 min-1hr Firefox crashes when it is using WEB GL on Google Maps.
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
RESOLVED
FIXED
mozilla14
People
(Reporter: autismm, Assigned: bjacob)
References
Details
(Keywords: crash)
Attachments
(4 files, 4 obsolete files)
26.10 KB,
text/plain
|
Details | |
6.56 KB,
patch
|
joe
:
review+
|
Details | Diff | Splinter Review |
don't try to fall back to another GL provider, if one GL provider gives a WebGL initialization error
2.40 KB,
patch
|
jgilbert
:
review+
|
Details | Diff | Splinter Review |
913 bytes,
patch
|
jgilbert
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Build ID: 20111220165912 Steps to reproduce: I was using Google Maps Web GL Functionality to take advantage of my plugin free Street View Environment Actual results: Every 30 min-1 hr, Firefox crashes every time or creates black lines Expected results: Firefox Should allow us to use Google Maps GL With out any crashes, as well as Google Street View experience without a plugin.
Crash Signature: EMPTY: no crashing thread identified; corrupt dump
I was keep getting crashes on firefox WEB GL after using Google maps every 30 min-1hr, can you please take action?
First, you go in to maps.google.com, click on experience maps with WEB GL, than go on Google Street View for at least 1 hour, than reproduce this crash.
Attachment #584202 -
Flags: checkin?(alex-pub.firefox-bugzilla)
Attachment #584202 -
Flags: approval-mozilla-release?
Attachment #584202 -
Flags: approval-mozilla-beta?
Attachment #584202 -
Flags: approval-mozilla-aurora?
Updated•13 years ago
|
Attachment #584202 -
Attachment is obsolete: true
Attachment #584202 -
Attachment is patch: false
Attachment #584202 -
Attachment mime type: text/plain → application/octet-stream
Attachment #584202 -
Flags: checkin?(alex-pub.firefox-bugzilla)
Attachment #584202 -
Flags: approval-mozilla-release?
Attachment #584202 -
Flags: approval-mozilla-beta?
Attachment #584202 -
Flags: approval-mozilla-aurora?
Comment 3•13 years ago
|
||
Please provide a new crash ID (the given one is useless) and please post the graphic section from about:support here. Why did you attach a "firefox.exe" ?
Priority: P1 → --
Application Basics Name Firefox Version 9.0.1 User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Profile Directory Open Containing Folder Enabled Plugins about:plugins Build Configuration about:buildconfig Crash Reports about:crashes Memory Use about:memory Extensions Name Version Enabled ID Norton Toolbar 2011.7.4.3 true {2D3F3651-74B9-4795-BDEC-6DA2F431CB62} Symantec IPS 3.2 true {BBDA0591-3099-440a-AA10-41764D9DB4DB} Norton Safety Minder 2.2.0.40 false {6D5C8FC4-DE46-41bf-9092-93F0F78E9115} Modified Preferences Name Value browser.places.smartBookmarksVersion 2 browser.startup.homepage_override.buildID 20111220165912 browser.startup.homepage_override.mstone rv:9.0.1 dom.indexedDB.enabled false extensions.lastAppVersion 9.0.1 network.cookie.prefsMigrated true places.database.lastMaintenance 1324782486 places.history.expiration.transient_current_max_pages 104858 places.history.expiration.transient_optimal_database_size 167772160 privacy.cpd.siteSettings true privacy.donottrackheader.enabled true privacy.sanitize.migrateFx3Prefs true privacy.sanitize.timeSpan 0 security.warn_viewing_mixed false Graphics Adapter Description NVIDIA GeForce GT 230 Vendor ID 10de Device ID 0603 Adapter RAM 1536 Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Driver Version 8.17.12.8562 Driver Date 10-15-2011 Adapter RAM (GPU #2) Unknown Adapter Drivers (GPU #2) Unknown Direct2D Enabled true DirectWrite Enabled true (6.1.7601.17563) ClearType Parameters ClearType parameters not found WebGL Renderer Google Inc. -- ANGLE (NVIDIA GeForce GT 230) -- OpenGL ES 2.0 (ANGLE 0.0.0.809) GPU Accelerated Windows 1/1 Direct3D 10
Crash Signature: EMPTY: no crashing thread identified; corrupt dump → bp-180c5e08-3fff-4298-bbf1-410962111224
Crash Signature: bp-180c5e08-3fff-4298-bbf1-410962111224 → 180c5e08-3fff-4298-bbf1-410962111224
(In reply to Matthias Versen (Matti) from comment #3) > Please provide a new crash ID (the given one is useless) and please post the > graphic section from about:support here. > > Why did you attach a "firefox.exe" ? Application Basics Name Firefox Version 9.0.1 User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Profile Directory Open Containing Folder Enabled Plugins about:plugins Build Configuration about:buildconfig Crash Reports about:crashes Memory Use about:memory Extensions Name Version Enabled ID Norton Toolbar 2011.7.4.3 true {2D3F3651-74B9-4795-BDEC-6DA2F431CB62} Symantec IPS 3.2 true {BBDA0591-3099-440a-AA10-41764D9DB4DB} Norton Safety Minder 2.2.0.40 false {6D5C8FC4-DE46-41bf-9092-93F0F78E9115} Modified Preferences Name Value browser.places.smartBookmarksVersion 2 browser.startup.homepage_override.buildID 20111220165912 browser.startup.homepage_override.mstone rv:9.0.1 dom.indexedDB.enabled false extensions.lastAppVersion 9.0.1 network.cookie.prefsMigrated true places.database.lastMaintenance 1324782486 places.history.expiration.transient_current_max_pages 104858 places.history.expiration.transient_optimal_database_size 167772160 privacy.cpd.siteSettings true privacy.donottrackheader.enabled true privacy.sanitize.migrateFx3Prefs true privacy.sanitize.timeSpan 0 security.warn_viewing_mixed false Graphics Adapter Description NVIDIA GeForce GT 230 Vendor ID 10de Device ID 0603 Adapter RAM 1536 Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Driver Version 8.17.12.8562 Driver Date 10-15-2011 Adapter RAM (GPU #2) Unknown Adapter Drivers (GPU #2) Unknown Direct2D Enabled true DirectWrite Enabled true (6.1.7601.17563) ClearType Parameters ClearType parameters not found WebGL Renderer Google Inc. -- ANGLE (NVIDIA GeForce GT 230) -- OpenGL ES 2.0 (ANGLE 0.0.0.809) GPU Accelerated Windows 1/1 Direct3D 10 Crash id: 180c5e08-3fff-4298-bbf1-410962111224
Updated•13 years ago
|
Component: General → Canvas: WebGL
Product: Firefox → Core
QA Contact: general → canvas.webgl
Comment 6•13 years ago
|
||
Does it happen in safe mode (see https://support.mozilla.org/en-US/kb/Safe%20Mode) because Norton's extensions are known to be crashy?
Crash Signature: 180c5e08-3fff-4298-bbf1-410962111224
Keywords: crash
(In reply to Scoobidiver from comment #6) > Does it happen in safe mode (see > https://support.mozilla.org/en-US/kb/Safe%20Mode) because Norton's > extensions are known to be crashy? yes, this issues does happen in Safe-Mode.
Comment 8•13 years ago
|
||
What about Nightly you can download from http://nightly.mozilla.org/?
(In reply to Scoobidiver from comment #8) > What about Nightly you can download from http://nightly.mozilla.org/? In nighty versions of Firefox, It is very slow to render Google Maps on Web GL. I can still experience this same issue as Firefox 9.0.1.
Comment 10•13 years ago
|
||
Can you attach in this bug a stack trace using Nightly and WinDbg (see https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg)?
Reporter | ||
Comment 11•13 years ago
|
||
(In reply to Scoobidiver from comment #10) > Can you attach in this bug a stack trace using Nightly and WinDbg (see > https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg)? I'm sending you an attatchment to this issue!
Reporter | ||
Comment 12•13 years ago
|
||
With Firefox nighty, google street view is very slow to use on Web GL
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•13 years ago
|
Attachment #586806 -
Attachment description: This attatchment is a test case in firefox nighty → WinDbg log
Assignee | ||
Comment 13•13 years ago
|
||
This crash report is corrupt ( https://crash-stats.mozilla.com/report/index/bp-180c5e08-3fff-4298-bbf1-410962111224 , see "EMPTY: no crashing thread identified; corrupt dump"). Can you go to about:crashes and see if you have other non-corrupt crash reports? The only interesting thing I can see there is "WGL+". It means that it's using the OpenGL driver, not ANGLE, for rendering. On the other hand, your about:support copy above says it's using ANGLE. So it's all very confusing. In about:config, is webgl.prefer-native-gl true? If yes, set it to false. Does that fix the problem? The WinDbg log says that exit() was called, which explains why Firefox terminated, but the stack is corrupt just below that frame so we can't know who called exit().
Assignee | ||
Comment 14•13 years ago
|
||
Oh, something else: D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ WGL? WGL+ This means that the first time it created a WebGL context, it used ANGLE (EGL?) and that succeeded (EGL+) so that first WebGL context was successfully created with ANGLE (WebGL+); but then for a subsequent WebGL context it used WGL. The reason for that can't be a failure to use ANGLE again, as there is no EGL- here. So it seems that you played with the webgl.prefer-native-gl preference?
Reporter | ||
Comment 15•13 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #14) > Oh, something else: > > D2D? D2D+ > DWrite? DWrite+ > D3D10 Layers? D3D10 Layers+ > WebGL? EGL? EGL+ > GL Context? GL Context+ > WebGL+ > WGL? WGL+ > > This means that the first time it created a WebGL context, it used ANGLE > (EGL?) and that succeeded (EGL+) so that first WebGL context was > successfully created with ANGLE (WebGL+); but then for a subsequent WebGL > context it used WGL. The reason for that can't be a failure to use ANGLE > again, as there is no EGL- here. So it seems that you played with the > webgl.prefer-native-gl preference? It is already set to false, But however, it did not fix the problem as possible.
Reporter | ||
Comment 16•13 years ago
|
||
(In reply to autismm from comment #15) > (In reply to Benoit Jacob [:bjacob] from comment #14) > > Oh, something else: > > > > D2D? D2D+ > > DWrite? DWrite+ > > D3D10 Layers? D3D10 Layers+ > > WebGL? EGL? EGL+ > > GL Context? GL Context+ > > WebGL+ > > WGL? WGL+ > > > > This means that the first time it created a WebGL context, it used ANGLE > > (EGL?) and that succeeded (EGL+) so that first WebGL context was > > successfully created with ANGLE (WebGL+); but then for a subsequent WebGL > > context it used WGL. The reason for that can't be a failure to use ANGLE > > again, as there is no EGL- here. So it seems that you played with the > > webgl.prefer-native-gl preference? > It is already set to false, But however, it did not fix the problem as > possible. Update 1: However we did not played with webGL Preference.
Reporter | ||
Comment 17•13 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #13) > This crash report is corrupt ( > https://crash-stats.mozilla.com/report/index/bp-180c5e08-3fff-4298-bbf1- > 410962111224 , see "EMPTY: no crashing thread identified; corrupt dump"). > Can you go to about:crashes and see if you have other non-corrupt crash > reports? > The only interesting thing I can see there is "WGL+". It means that it's > using the OpenGL driver, not ANGLE, for rendering. On the other hand, your > about:support copy above says it's using ANGLE. So it's all very confusing. > In about:config, is webgl.prefer-native-gl true? If yes, set it to false. > Does that fix the problem? > The WinDbg log says that exit() was called, which explains why Firefox > terminated, but the stack is corrupt just below that frame so we can't know > who called exit(). Setting this to false did not fix the problem. I don't have any non corrupt crash reports.
Assignee | ||
Comment 18•13 years ago
|
||
ok. it could be that we need to blacklist WGL on NVIDIA cards as well... but it's a pity as we were hoping to be able to use it more (it could bring performance benefits). Maybe the first thing to do is grep through crash_analysis to see how many crash reports show WGL.
Assignee | ||
Comment 19•13 years ago
|
||
bjacob@cahouette:~$ grep WebGL[+] 20120102-pub-crashdata.csv | wc -l 1647 bjacob@cahouette:~$ grep WebGL[+] 20120102-pub-crashdata.csv | grep WGL[+] | wc -l 12 bjacob@cahouette:~$ grep WebGL[+] 20120102-pub-crashdata.csv | grep WGL[+] | grep EGL[+] | wc -l 9 bjacob@cahouette:~$ grep WebGL[+] 20120102-pub-crashdata.csv | grep WGL[+] | grep corrupt | wc -l 2 bjacob@cahouette:~$ grep WebGL[+] 20120102-pub-crashdata.csv | grep WGL[+] | grep EGL[+] | grep corrupt | wc -l 1 OK so this tells us that on Jan 02, there have been 1647 crash reports from sessions where WebGL had been successfully initialized; 12 of them had used WGL (less than 1% of the WebGL-using ones); out of them, 9 had also used EGL; most of them are NOT corrupt. Here are the non-corrupt crash reports that used WGL: bjacob@cahouette:~$ grep WebGL[+] 20120102-pub-crashdata.csv | grep WGL[+] | grep -v corrupt | sed 's/.*http\:\/\/crash\-stats/http\:\/\/crash\-stats/' | sed 's/[\ \t].*//' http://crash-stats.mozilla.com/report/index/faedfcfb-1d8f-4798-8432-184482120102 http://crash-stats.mozilla.com/report/index/56ec972d-029c-4b70-be8e-598e32120102 http://crash-stats.mozilla.com/report/index/d4aac20a-2c6c-43ff-abdf-e92422120102 http://crash-stats.mozilla.com/report/index/503d0819-458c-4896-a9fb-9325e2120102 http://crash-stats.mozilla.com/report/index/9f19eacc-e784-45c8-9ca8-ed2c52120102 http://crash-stats.mozilla.com/report/index/8d214859-c81a-463f-b86c-51b382120102 http://crash-stats.mozilla.com/report/index/540f282c-ed10-416f-a116-f791c2120102 http://crash-stats.mozilla.com/report/index/68df1395-6dd3-4cc4-897e-2a9fd2120102 http://crash-stats.mozilla.com/report/index/5040dfa0-06f7-49f8-a21a-58a052120102 http://crash-stats.mozilla.com/report/index/3dfdef88-8a81-4653-98c5-65b752120102
Assignee | ||
Comment 20•13 years ago
|
||
Out of these 10 crash reports with WGL+ WebGL+, 6 are in the NVIDIA OpenGL driver. Although the sample size is tiny, this suggests that WGL is actually very crashy for NVIDIA users. Seems that we have to blacklist, like we do on ATI and Intel cards.
Assignee | ||
Comment 21•13 years ago
|
||
This patch also moves a NVIDIA blacklist entry up to the NVIDIA block. https://tbpl.mozilla.org/?tree=Try&rev=cf4a0708e8f6
Attachment #586856 -
Flags: review?(joe)
Reporter | ||
Comment 22•13 years ago
|
||
Comment on attachment 586856 [details] [diff] [review] blacklist WGL altogether Review of attachment 586856 [details] [diff] [review]: ----------------------------------------------------------------- I agree with this.
Comment 23•13 years ago
|
||
I'm not greatly convinced we should jump directly to blacklisting WGL for all NVidia. In looking at the 6 of those 10 crash reports that crashed in nvoglv32.dll, they all used driver 258.96, so maybe that's a start. We do need to understand better why we're falling back to WGL when it doesn't seem like we should be, but I don't think blacklisting is the way to fix that. At this point, we can't even be sure this bug is caused by WGL. I don't think there is currently a method to disable WGL, but we should probably add one. Even if not, it would be useful to create a try build with WGL disabled (or disablable) to make sure that it is WGL that is causing this crash. (I will put one up in a few minutes, though it'll take a couple hours to build on try) Also, what would be causing useless crash logs? I will try to replicate the crash locally, but having useful crashlogs would be more ideal.
Assignee | ||
Comment 24•13 years ago
|
||
(In reply to Jeff Gilbert [:jgilbert] from comment #23) > I'm not greatly convinced we should jump directly to blacklisting WGL for > all NVidia. In looking at the 6 of those 10 crash reports that crashed in > nvoglv32.dll, they all used driver 258.96, so maybe that's a start. Good point; the present bug is on 285.62 but we don't know that it's the same. > > We do need to understand better why we're falling back to WGL when it > doesn't seem like we should be, but I don't think blacklisting is the way to > fix that. True, let's try to understand that. > > At this point, we can't even be sure this bug is caused by WGL. I don't > think there is currently a method to disable WGL, but we should probably add > one. Even if not, it would be useful to create a try build with WGL disabled > (or disablable) to make sure that it is WGL that is causing this crash. (I > will put one up in a few minutes, though it'll take a couple hours to build > on try) My above try build is ready: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-cf4a0708e8f6/ > Also, what would be causing useless crash logs? I will try to replicate the > crash locally, but having useful crashlogs would be more ideal. Not sure. Some kinds of heap and/or stack corruption, I guess.
Updated•13 years ago
|
Attachment #586856 -
Flags: review?(joe) → review+
Assignee | ||
Comment 25•13 years ago
|
||
Can you try this build, does it fix the problem? http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-cf4a0708e8f6/
Assignee | ||
Comment 26•13 years ago
|
||
I downloaded two more days of crash data: bjacob@cahouette:~$ grep WebGL[+] 20120103-pub-crashdata.csv | grep WGL[+] | grep -v corrupt | sed 's/.*http\:\/\/crash\-stats/http\:\/\/crash\-stats/' | sed 's/[\ \t].*//' http://crash-stats.mozilla.com/report/index/a64a811e-b9b3-4a39-bc65-835ee2120103 http://crash-stats.mozilla.com/report/index/361ddbb4-0ac4-4418-aa80-ae2dc2120103 http://crash-stats.mozilla.com/report/index/baf319f4-b947-4312-90f1-5834d2120103 http://crash-stats.mozilla.com/report/index/82432a9b-47cb-40d7-9ec5-3211a2120103 http://crash-stats.mozilla.com/report/index/1f6eefbb-72e8-47df-9943-c013d2120103 http://crash-stats.mozilla.com/report/index/66e06f4f-8c48-4e68-9395-072722120103 http://crash-stats.mozilla.com/report/index/69693b2c-e25d-41c1-a993-213362120103 http://crash-stats.mozilla.com/report/index/576d492a-e575-4521-89d4-8314c2120103 http://crash-stats.mozilla.com/report/index/4c4a3de5-ce8c-4373-9060-a715b2120103 http://crash-stats.mozilla.com/report/index/1237da1c-d0df-448d-9c94-17e9f2120103 http://crash-stats.mozilla.com/report/index/b0114a61-2408-4e97-845c-bdd912120103 http://crash-stats.mozilla.com/report/index/210bef19-36a0-44b5-928e-a62202120103 http://crash-stats.mozilla.com/report/index/5a7f65a6-c718-4c76-8d7e-845c22120103 http://crash-stats.mozilla.com/report/index/0001edfa-24ff-4c09-a50b-a41692120103 http://crash-stats.mozilla.com/report/index/28a417e7-3051-44ef-8d84-e00642120103 http://crash-stats.mozilla.com/report/index/2030976c-16e3-4570-87e2-2f30e2120103 http://crash-stats.mozilla.com/report/index/71a2abb1-5e4e-4190-83a8-0b9e12120103 bjacob@cahouette:~$ grep WebGL[+] 20120104-pub-crashdata.csv | grep WGL[+] | grep -v corrupt | sed 's/.*http\:\/\/crash\-stats/http\:\/\/crash\-stats/' | sed 's/[\ \t].*//' http://crash-stats.mozilla.com/report/index/44a6f804-c7b8-4f37-966a-ee3a42120104 http://crash-stats.mozilla.com/report/index/0156527a-b952-4649-9132-f6a712120104 http://crash-stats.mozilla.com/report/index/bfefbf26-68ea-43d0-a10e-dfabd2120104 http://crash-stats.mozilla.com/report/index/90314e29-ee7c-4de6-b481-f79852120104 http://crash-stats.mozilla.com/report/index/b7c62520-5ba0-4c2d-97e2-bc75d2120104 http://crash-stats.mozilla.com/report/index/7e0cd416-b5ba-4a55-8622-82abd2120104 http://crash-stats.mozilla.com/report/index/78ed7c7d-4add-4838-8814-dc1682120104 http://crash-stats.mozilla.com/report/index/9fcf79b9-fdcc-4e4c-b2d4-fae7c2120104 http://crash-stats.mozilla.com/report/index/e698a5ab-28e0-4aa1-9d94-7da102120104 http://crash-stats.mozilla.com/report/index/980955e5-5f05-45b2-b5fa-ce8802120104 http://crash-stats.mozilla.com/report/index/9b160c99-3cec-4bd0-9a20-5d1542120104 http://crash-stats.mozilla.com/report/index/e707d085-b256-4f16-83d2-413e72120104 http://crash-stats.mozilla.com/report/index/69d7efb5-0975-41be-a5b8-ce1362120104 http://crash-stats.mozilla.com/report/index/576f200a-a4d2-49f7-9790-476742120104 http://crash-stats.mozilla.com/report/index/db12bf94-4e04-46b2-a05f-2be3b2120104
Assignee | ||
Comment 27•13 years ago
|
||
Already this one, https://crash-stats.mozilla.com/report/index/0156527a-b952-4649-9132-f6a712120104 is on a different NVIDIA driver version: 268.30 These two new days of crash reports confirm that a majority of crashes with WGL+ WebGL+ are crashes of the NVIDIA OpenGL driver.
Assignee | ||
Comment 28•13 years ago
|
||
This one is even on NVIDIA 285.58: https://crash-stats.mozilla.com/report/index/66e06f4f-8c48-4e68-9395-072722120103 Aside of these NVIDIA OpenGL crashes, we also have various Firefox crashes on null pointer deref with stacks strongly suggesting that it's the GL context or D3D equivalent that got null: https://crash-stats.mozilla.com/report/index/361ddbb4-0ac4-4418-aa80-ae2dc2120103 https://crash-stats.mozilla.com/report/index/baf319f4-b947-4312-90f1-5834d2120103 Not sure how we get there.
Reporter | ||
Comment 29•13 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #25) > Can you try this build, does it fix the problem? > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com- > cf4a0708e8f6/ No, This problem got even worse
Reporter | ||
Comment 30•13 years ago
|
||
(In reply to autismm from comment #29) > (In reply to Benoit Jacob [:bjacob] from comment #25) > > Can you try this build, does it fix the problem? > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com- > > cf4a0708e8f6/ > > No, This problem got even worse Update1: It also disabled Google street view functionality via WEB GL in maps.google.com? Maps GL Still works on Google maps.
Reporter | ||
Comment 31•13 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #25) > Can you try this build, does it fix the problem? > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com- > cf4a0708e8f6/ Update1: It also disabled Google street view functionality via WEB GL in maps.google.com? Maps GL Still works on Google maps.
Comment 32•13 years ago
|
||
Alright, it looks like we need to blacklist this for the time being. We should have a plan for unblacklisting, though.
Assignee | ||
Comment 33•13 years ago
|
||
(In reply to autismm from comment #29) > (In reply to Benoit Jacob [:bjacob] from comment #25) > > Can you try this build, does it fix the problem? > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com- > > cf4a0708e8f6/ > > No, This problem got even worse Can you please describe precisely the problem, with this build? This build blacklists OpenGL. This means that if it tries to use the OpenGL driver for WebGL rendering, it will fail. The expected result is no rendering, but also no crash. Do you still get crashes with this build? If yes, please go to about:crashes and give me a crash link.
Reporter | ||
Comment 34•13 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #33) > (In reply to autismm from comment #29) > > (In reply to Benoit Jacob [:bjacob] from comment #25) > > > Can you try this build, does it fix the problem? > > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com- > > > cf4a0708e8f6/ > > > > No, This problem got even worse > > Can you please describe precisely the problem, with this build? > > This build blacklists OpenGL. This means that if it tries to use the OpenGL > driver for WebGL rendering, it will fail. The expected result is no > rendering, but also no crash. Do you still get crashes with this build? If > yes, please go to about:crashes and give me a crash link. No, I don't get any crashes with this build, However I agree with this statement.
Assignee | ||
Comment 35•13 years ago
|
||
I think I have a clue into why we are sometimes falling back to WGL without any EGL initialization failure reported. Once we have a GL context, we proceed to initialize WebGL with it. That's WebGLContext::InitAndValidateGL(). That function is quite non-clearly-deterministic, with plenty of opportunity for both the GL and the ANGLE shader compiler to cause a failure. When we get a failure there, WebGLContext::SetDimensions proceeds to try another context provider. That's how we got into this situation! This patch makes us not try to continue after InitAndValidateGL failed. This should theoretically never happen, anyways, so if it does happen, something really evil is going on and rather than playing with WebGL, we should lock ourselves in a church with a wooden pike, garlic, and a crucifix.
Attachment #588144 -
Flags: review?(jgilbert)
Assignee | ||
Comment 36•13 years ago
|
||
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-0bb19b754097
Reporter | ||
Comment 37•13 years ago
|
||
Comment on attachment 588144 [details] [diff] [review] don't try to fall back to another GL provider, if one GL provider gives a WebGL initialization error Review of attachment 588144 [details] [diff] [review]: ----------------------------------------------------------------- I agree with this.
Comment 38•13 years ago
|
||
Comment on attachment 588144 [details] [diff] [review] don't try to fall back to another GL provider, if one GL provider gives a WebGL initialization error Review of attachment 588144 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. I like this change. Hopefully this should eliminate the spurious usage of fallback renderers.
Attachment #588144 -
Flags: review?(jgilbert) → review+
Assignee | ||
Comment 40•12 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/ca2f62afaf0d
Assignee: nobody → bjacob
Target Milestone: --- → mozilla12
Reporter | ||
Comment 41•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #40) > http://hg.mozilla.org/integration/mozilla-inbound/rev/ca2f62afaf0d I agree with this information
Comment 42•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ca2f62afaf0d
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 43•12 years ago
|
||
(In reply to Justin Wood (:Callek) from comment #42) > https://hg.mozilla.org/mozilla-central/rev/ca2f62afaf0d I agree with this information.
Assignee | ||
Comment 44•12 years ago
|
||
Sorry, let's keep this bug open for now until it's confirmed to be fixed. @ autismm, do the crashes still occur?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 45•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #44) > @ autismm, do the crashes still occur? The test must be done in 12.0a1/20120117.
Assignee | ||
Comment 46•12 years ago
|
||
So, does this crash still occur for you?
Reporter | ||
Comment 47•12 years ago
|
||
maybe, It might occur to us anytime
Assignee | ||
Comment 48•12 years ago
|
||
What do you mean? Can you now use Google MapsGL for more than a hour, or does it still crash?
Reporter | ||
Comment 49•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #48) > What do you mean? Can you now use Google MapsGL for more than a hour, or > does it still crash? It still crashes
Assignee | ||
Comment 50•12 years ago
|
||
The only place where we still tolerate an initialization error is the final osmesa-as-a-fallback attempt.
Attachment #600544 -
Flags: review?(jgilbert)
Assignee | ||
Comment 51•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=a9b2f30793f7
Comment 52•12 years ago
|
||
Comment on attachment 600544 [details] [diff] [review] don't try to fall back to another GL provider, *at all* There's nothing here! D:
Attachment #600544 -
Flags: review?(jgilbert) → review-
Reporter | ||
Comment 53•12 years ago
|
||
Comment on attachment 600544 [details] [diff] [review] don't try to fall back to another GL provider, *at all* approve this bug
Reporter | ||
Comment 54•12 years ago
|
||
Comment on attachment 600544 [details] [diff] [review] don't try to fall back to another GL provider, *at all* approve this fix
Assignee | ||
Comment 55•12 years ago
|
||
Chuck Norris doesn't need to write code. The computer just obeys.
Attachment #600677 -
Flags: review?(jgilbert)
Reporter | ||
Comment 56•12 years ago
|
||
Comment on attachment 600677 [details] [diff] [review] don't try to fall back to another GL provider, *at all* Review of attachment 600677 [details] [diff] [review]: ----------------------------------------------------------------- I agree with this plan
Assignee | ||
Comment 57•12 years ago
|
||
Review ping!
Comment 58•12 years ago
|
||
Comment on attachment 600677 [details] [diff] [review] don't try to fall back to another GL provider, *at all* Review of attachment 600677 [details] [diff] [review]: ----------------------------------------------------------------- r- to be sure we don't regress bug 727178. ::: content/canvas/src/WebGLContext.cpp @@ +495,3 @@ > } > + if (useANGLE) > + gl->SetFlushGuaranteesResolve(true); Some bit rot from bug 727178: Just delete this part.
Attachment #600677 -
Flags: review?(jgilbert) → review-
Assignee | ||
Comment 59•12 years ago
|
||
1k should be enough for anybody
Attachment #600544 -
Attachment is obsolete: true
Attachment #600677 -
Attachment is obsolete: true
Attachment #603593 -
Flags: review?(jgilbert)
Comment 60•12 years ago
|
||
Comment on attachment 603593 [details] [diff] [review] don't try to fall back to another GL provider, *at all* Review of attachment 603593 [details] [diff] [review]: ----------------------------------------------------------------- Right code, wrong block. Also, let's be sure that even with disabled fall-through, prefer-native-gl allows us to force WGL. (It looks like it should, anyways) ::: content/canvas/src/WebGLContext.cpp @@ +495,5 @@ > } > } > #endif > > // try the default provider, whatever that is So this is actually the WGL block on windows. Can we add a comment about what this block should be on which platforms? Windows: WGL, Mac: CGL, Linux: GLX, Mobile: EGL, if I recall correctly.
Attachment #603593 -
Flags: review?(jgilbert) → review-
Reporter | ||
Comment 61•12 years ago
|
||
(In reply to Jeff Gilbert [:jgilbert] from comment #60) > Comment on attachment 603593 [details] [diff] [review] > don't try to fall back to another GL provider, *at all* > > Review of attachment 603593 [details] [diff] [review]: > ----------------------------------------------------------------- > > Right code, wrong block. > > Also, let's be sure that even with disabled fall-through, prefer-native-gl > allows us to force WGL. (It looks like it should, anyways) > > ::: content/canvas/src/WebGLContext.cpp > @@ +495,5 @@ > > } > > } > > #endif > > > > // try the default provider, whatever that is > > So this is actually the WGL block on windows. > Can we add a comment about what this block should be on which platforms? > Windows: WGL, Mac: CGL, Linux: GLX, Mobile: EGL, if I recall correctly. yes, All platforms.
Assignee | ||
Comment 62•12 years ago
|
||
good catch!
Attachment #603593 -
Attachment is obsolete: true
Attachment #603814 -
Flags: review?(jgilbert)
Assignee | ||
Comment 63•12 years ago
|
||
(In reply to Jeff Gilbert [:jgilbert] from comment #60) Can we add a comment about what this block should be on which platforms? > Windows: WGL, Mac: CGL, Linux: GLX, Mobile: EGL, if I recall correctly. The list is correct (except of course that Windows/ANGLE is EGL, and that in the future we'll probably continue seeing EGL appear in more places and switch to it). Not sure what comment you would like me to add here? Anyway, do add any comment you find useful and I'll r+.
Reporter | ||
Comment 64•12 years ago
|
||
Comment on attachment 603814 [details] [diff] [review] don't try to fall back to another GL provider, *at all* I agree with this
Comment 65•12 years ago
|
||
Comment on attachment 603814 [details] [diff] [review] don't try to fall back to another GL provider, *at all* Review of attachment 603814 [details] [diff] [review]: ----------------------------------------------------------------- I'll try to put in a comment when I next touch that code.
Attachment #603814 -
Flags: review?(jgilbert) → review+
Assignee | ||
Comment 66•12 years ago
|
||
Forgot to land that one!! http://hg.mozilla.org/integration/mozilla-inbound/rev/0684dcf0e756
Target Milestone: mozilla12 → mozilla14
Comment 67•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0684dcf0e756
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•