801699 - crash in mozilla::gl::GLContext::AssembleOffscreenFBOs @ fglrx_dri with AMD GPUs

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Layers, defect)

Description

[Simona Badau, Desktop QA]

This bug was filed from the Socorro interface and is 
report bp-9f917891-b02c-4bc5-b5a0-bac792121015 .
============================================================= 

I stumbled upon this issue while verifying Bug 774688. Firefox crashes while viewing WebGL demos having the pref ayers.acceleration.disabled set to true.

Steps to reproduce:
1. Launch Firefox and set layers.acceleration.disabled=true
2. Navigate to a WebGL demo 
for e.g 
http://sandbox.ayzenberg.com/creative_prototypes/html5_/webgl/prototypeEightMe.html
http://sandbox.ayzenberg.com/creative_prototypes/html5_/webgl/prototypeEightLOD.html
http://webglsamples.googlecode.com/hg/aquarium/aquarium.html
http://lights.elliegoulding.com/

Expected results:
The WebGL demos are properly loading.

Actual results:
Within a few seconds - Firefox crashes.

Please note that I could reproduce this crash on a computer running Ubuntu with the following driver: ATI Technologies Inc. -- ATI Radeon 3000 Graphics -- 3.3.11627 Compatibility Profile Context.
I couldn't reproduce the crash on a computer running Ubuntu with NVidia.

Comment 1

[Simona Badau, Desktop QA]

So far I could reproduce this crash on the latest Nightly, on Firefox 17 beta 1, on Firefox 10.0.1.
I will work tomorrow on a regression range.

Comment 2

[nemo]

I ran into this while experimenting w/ increasing dimensions of a small GOL page.

At 512x512, ran fine. So did 512x1024 although it looked odd, since it assumed same width/height.
Increased to 1024x1024, and it crashed.

http://static.patater.com/life.html was the page I was experimenting with.
I'd just modified function J() so that on load, i/j were set to different values, and l.width/height set similarly.

Interestingly, larger values *had* worked for a while.  But this sucky fglrx driver does start failing on large textures after a while.
Leaking I expect :(
Restarting X, and 1024x1024 started working again.  But eventually larger values started crashing.

Anyway, this bug was linked in the crash report, so I figured I'd mention it.
[  2582.505] (II) Loading /usr/lib/x86_64-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/modules/linux/libfglrxdrm.so
[  2582.505] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
[  2582.505]    compiled for 1.4.99.906, module version = 8.96.4

Comment 3

[nemo]

Heh, reading his code I see:
  if (mod_pixels_dirty) {                                                                                                            
    gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true);                                                                                    
    gl.texImage2D(                                                                                                                   
        gl.TEXTURE_2D, 0, gl.RGBA, width, height,                                                                                    
        0, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(mod_pixels)                                                                     
    );                                                                                                                               
    // XXX I hope the old array gets garbage collected.   

Given behaviour gets worse and worse over time, I'm guessing, no? :)

Comment 4

[Simona Badau, Desktop QA]

Last good nightly: 2011-11-06
First bad nightly: 2011-11-07

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7e28b68cf25d&tochange=161c6106d787

There is no need to set the preference layers.acceleration.disabled to true (Firefox crashes no matter how the preference is set).

Comment 5

[Scoobidiver (away)]

(In reply to Simona B [QA] from comment #4)
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=7e28b68cf25d&tochange=161c6106d787
It's likely related to the change in blocklisting.

Comment 6

[u279076]

Looking at the graph for the last month it appears to have spiked on Sept 7th and has been trailing off ever since.

https://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&reason_type=contains&range_value=4&range_unit=weeks&hang_type=any&process_type=any&signature=fglrx_dri.so%400x1196a1a

Given the low crash volume I'm questioning whether this should be deemed critical.

Comment 7

[Scoobidiver (away)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #6)
> Given the low crash volume I'm questioning whether this should be deemed
> critical.
A crash is always critical whatever its volume.

Comment 8

[u279076]

(In reply to Scoobidiver from comment #7)
> A crash is always critical whatever its volume.

Ah yes, you are right. My mistake.

Comment 9

[u279076]

This crash has been reported four times in the last year, 3 with Firefox 14, once with Firefox 45.0.2. By the looks of the metadata it is isolated to a single user. Unfortunately I don't see us fixing this any time soon, if ever. As such I am marking this bug as incomplete. Please reopen if this is something you think we can/should fix.

Comment 10

[nemo]

Hm. Clearly not a single user since it hit me too. ☺

My AMD card on my linux machine at work regularly crashes Firefox, but I accept it since I'm overriding the webgl blacklist so I get what I deserve.  Old crappy AMD card + sucky driver, what do you expect.

Would not surprise me if original bug filer is doing same thing.  Force enabling acceleration also triggers non-webgl crashes...

Anyway, totally understandable that it wouldn't be something you guys can reasonable spend resources on.