713369 - Between 30 min-1hr Firefox crashes when it is using WEB GL on Google Maps.

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[autismm]

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.

Comment 1

[autismm]

I was keep getting crashes on firefox WEB GL after using Google maps every 30 min-1hr, can you please take action?

Comment 2

[autismm]

Attachment: Firefox 9

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.

Comment 3

[Matthias Versen [:Matti]]

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" ?

Comment 4

[autismm]

  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

Comment 5

[autismm]

(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

Comment 6

[Scoobidiver (away)]

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?

Comment 7

[autismm]

(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

[Scoobidiver (away)]

What about Nightly you can download from http://nightly.mozilla.org/?

Comment 9

[autismm]

(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

[Scoobidiver (away)]

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

Comment 11

[autismm]

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

Comment 12

[autismm]

Attachment: WinDbg log

With Firefox nighty, google street view is very slow to use on Web GL

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

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?

Comment 15

[autismm]

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

Comment 16

[autismm]

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

Comment 17

[autismm]

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

Comment 18

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 19

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 20

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 21

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: blacklist WGL altogether

This patch also moves a NVIDIA blacklist entry up to the NVIDIA block.
https://tbpl.mozilla.org/?tree=Try&rev=cf4a0708e8f6

Comment 22

[autismm]

Comment on attachment 586856 [details] [diff] [review]
blacklist WGL altogether

Review of attachment 586856 [details] [diff] [review]:
-----------------------------------------------------------------

I agree with this.

Comment 23

[Kelsey Gilbert [:jgilbert]]

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.

Comment 24

[Benoit Jacob [:bjacob] (mostly away)]

(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/[e-mail]-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.

Comment 25

[Benoit Jacob [:bjacob] (mostly away)]

Can you try this build, does it fix the problem?
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-cf4a0708e8f6/

Comment 26

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 27

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 28

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 29

[autismm]

(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/[e-mail]-
> cf4a0708e8f6/

No, This problem got even worse

Comment 30

[autismm]

(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/[e-mail]-
> > 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.

Comment 31

[autismm]

(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/[e-mail]-
> 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

[Kelsey Gilbert [:jgilbert]]

Alright, it looks like we need to blacklist this for the time being. We should have a plan for unblacklisting, though.

Comment 33

[Benoit Jacob [:bjacob] (mostly away)]

(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/[e-mail]-
> > 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.

Comment 34

[autismm]

(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/[e-mail]-
> > > 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.

Comment 35

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: don't try to fall back to another GL provider, if one GL provider gives a WebGL initialization error

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.

Comment 36

[Benoit Jacob [:bjacob] (mostly away)]

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-0bb19b754097

Comment 37

[autismm]

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

[Kelsey Gilbert [:jgilbert]]

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.

Comment 40

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/ca2f62afaf0d

Comment 41

[autismm]

(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

[Justin Wood (:Callek)]

https://hg.mozilla.org/mozilla-central/rev/ca2f62afaf0d

Comment 43

[autismm]

(In reply to Justin Wood (:Callek) from comment #42)
> https://hg.mozilla.org/mozilla-central/rev/ca2f62afaf0d

I agree with this information.

Comment 44

[Benoit Jacob [:bjacob] (mostly away)]

Sorry, let's keep this bug open for now until it's confirmed to be fixed.

@ autismm, do the crashes still occur?

Comment 45

[Scoobidiver (away)]

(In reply to Benoit Jacob [:bjacob] from comment #44)
> @ autismm, do the crashes still occur?
The test must be done in 12.0a1/20120117.

Comment 46

[Benoit Jacob [:bjacob] (mostly away)]

So, does this crash still occur for you?

Comment 47

[autismm]

maybe, It might occur to us anytime

Comment 48

[Benoit Jacob [:bjacob] (mostly away)]

What do you mean? Can you now use Google MapsGL for more than a hour, or does it still crash?

Comment 49

[autismm]

(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

Comment 50

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: don't try to fall back to another GL provider, *at all*

The only place where we still tolerate an initialization error is the final osmesa-as-a-fallback attempt.

Comment 51

[Benoit Jacob [:bjacob] (mostly away)]

https://tbpl.mozilla.org/?tree=Try&rev=a9b2f30793f7

Comment 52

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 600544 [details] [diff] [review]
don't try to fall back to another GL provider, *at all*

There's nothing here! D:

Comment 53

[autismm]

Comment on attachment 600544 [details] [diff] [review]
don't try to fall back to another GL provider, *at all*

approve this bug

Comment 54

[autismm]

Comment on attachment 600544 [details] [diff] [review]
don't try to fall back to another GL provider, *at all*

approve this fix

Comment 55

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: don't try to fall back to another GL provider, *at all*

Chuck Norris doesn't need to write code. The computer just obeys.

Comment 56

[autismm]

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

Comment 57

[Benoit Jacob [:bjacob] (mostly away)]

Review ping!

Comment 58

[Kelsey Gilbert [:jgilbert]]

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.

Comment 59

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: don't try to fall back to another GL provider, *at all*

1k should be enough for anybody

Comment 60

[Kelsey Gilbert [:jgilbert]]

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.

Comment 61

[autismm]

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

Comment 62

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: don't try to fall back to another GL provider, *at all*

good catch!

Comment 63

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 64

[autismm]

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

[Kelsey Gilbert [:jgilbert]]

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.

Comment 66

[Benoit Jacob [:bjacob] (mostly away)]

Forgot to land that one!!

http://hg.mozilla.org/integration/mozilla-inbound/rev/0684dcf0e756

Comment 67

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/0684dcf0e756