1192648 - Crash with webgl and accelerated layers on linux with cairo (Nvidia Driver)

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect)

Description

[Stebs]

Attachment: Troubleshooting Information.txt

Reproducible crash with any webgl (I used attached url) and forcing accelerated layers: layers.acceleration.force-enabled;true
No crash with gfx.content.azure.backends;skia
No crash when accelerated layers are on default (off)

Used fresh profile to test, don't know any regression range, but I suspect it to be recent?

Graphics:
Adapter Description	NVIDIA Corporation -- GeForce GTX 560 Ti/PCIe/SSE2
Asynchronous Pan/Zoom	none
Device ID	GeForce GTX 560 Ti/PCIe/SSE2
Driver Version	4.5.0 NVIDIA 352.30
GPU Accelerated Windows	1/1 OpenGL (OMTC)
Supports Hardware H264 Decoding	false
Vendor ID	NVIDIA Corporation
WebGL Renderer	NVIDIA Corporation -- GeForce GTX 560 Ti/PCIe/SSE2
windowLayerManagerRemote	true
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0
CairoUseXRender	1

Crash id:
bp-345b767c-1e34-480c-ada5-2e2382150809

Comment 1

[Stebs]

User Agent: 	Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

Comment 2

[Stebs]

Same Nightly (Build ID 	20150809030213) on another machine with same Distribution but Intel GPU (HD4000) does not crash. So probably Nvidia Driver related.

Comment 4

[Stebs]

Are you sure this is a duplicate?
Thanks to the great mozregression, I just got an regression-range (First bad revision: aeb85029c3b3 (2015-08-01)) that lies after bug 1131540

Last good revision: ca53d4297f02
First bad revision: 284e48036311
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ca53d4297f02&tochange=284e48036311

So does this qualify as regression?

Comment 5

[Stebs]

Scrap my last regression-range.
Good range (newer mozregression) with OpenGl-related checkins:

Last good revision: c14a0de10f23
First bad revision: 189161dc1616
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c14a0de10f23&tochange=189161dc1616

Comment 6

[u279076]

[Tracking Requested - why for this release]: WebGL crash regression.

(In reply to Stebs from comment #5)
> Last good revision: c14a0de10f23
> First bad revision: 189161dc1616
> Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=c14a0de10f23&tochange=189161dc1616

Based on that range I do not think this is a duplicate of bug 1131540. Thanks for filing this bug and finding the range. Can you check to see if this reproduces  

Andrew, your changes might be to blame here. Can you please take a look?

Comment 7

[Andrew Comminos [:acomminos]]

I believe this issue to be caused by my fix to talos regressions with OGL layers disabled- when using E10S, gfxPlatform::GetPlatform()->GetCompositorBackend() returns mozilla::layers::LAYERS_NONE in the child, despite GL layers being used on the compositor side.

I plan on implementing GLX surface sharing when using basic (X11) layers- that should fix this problem.

Comment 8

[u279076]

(In reply to Andrew Comminos [:acomminos] from comment #7)
> I plan on implementing GLX surface sharing when using basic (X11) layers-
> that should fix this problem.

Is that work being tracked in a bug report? If so, can you please set this bug as dependent?

Comment 9

[John Schoenick [:johns]]

I'm crashing several times a day after this change - it would be nice if we could get a short term fix that isn't disabling hardware acceleration.

Comment 10

[Andrew Comminos [:acomminos]]

(In reply to John Schoenick [:johns] from comment #9)
> I'm crashing several times a day after this change - it would be nice if we
> could get a short term fix that isn't disabling hardware acceleration.

Short term fix is setting the pref `webgl.force-layers-readback` to true. Sorry about this, we're blocking on finding a good solution to fix this for GLX and EGL.

Comment 11

[John Schoenick [:johns]]

Ac(In reply to Andrew Comminos [:acomminos] from comment #10)
> (In reply to John Schoenick [:johns] from comment #9)
> > I'm crashing several times a day after this change - it would be nice if we
> > could get a short term fix that isn't disabling hardware acceleration.
> 
> Short term fix is setting the pref `webgl.force-layers-readback` to true.
> Sorry about this, we're blocking on finding a good solution to fix this for
> GLX and EGL.

Hmm, actually, I'm still seeing this with said webgl pref, but it seems to happen on pages separate from webgl. Are there multiple GL bugs in this range? Should I open another bug for non-webgl crashes? E.g.:

https://crash-stats.mozilla.com/report/index/610256e3-3d91-4e80-ba29-e26d82150821

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Andrew, do you have plans to work on this for 42? We are going to move to beta in about 2 weeks.

Tracking as it is an important regression.

Comment 13

[Andrew Comminos [:acomminos]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #12)
> Andrew, do you have plans to work on this for 42? We are going to move to
> beta in about 2 weeks.

The correct fix requires some significant changes to the way we handle GL context creation- it might be best to turn off GLX surface sharing with WebGL in 42 rather than uplift the context creation changes, which are not done yet. Would that be acceptable?

FYI my changes that caused this issue only cause problems on NVIDIA with OpenGL composition force-enabled (i.e. not the default config).

Comment 14

[Stebs]

Been away awhile, this no longer crashes with nigthly (Build ID 20151007030205).
Probably because Bug 1193015 got fixed?
So I guess I can close this now, since this Bug was about the crash with accelerated layers forced on (with cairo), and this no longer crashes for me...
Not sure if mentioned "correct fix" is handled in another Bug, so reopen if needed.