1376342 - Crash in [@ r300_dri.so@0x5f264a ] - crashes when loading pages or just switching or closing tabs

Status: RESOLVED WONTFIX

(Core :: Graphics: CanvasWebGL, defect, P3)

Description

[Vlad Godoroja]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170608175746

Steps to reproduce:

I have been getting "Gah. Your tab just crashed" for a month  (I guess). It worked just fine before. I use linux (openSUSE and Manjaro), and I get this error on both distros. 

I have tried the portable linux version from Mozilla website. I disabled the HWA, I tried the tips from the support pages. I tried the safe mode.

Below are the links to my crash reports:
https://crash-stats.mozilla.com/report/index/900902ea-77fd-401b-b8eb-55d2b0170626
https://crash-stats.mozilla.com/report/index/a2607899-5de9-4fb9-b050-e463e0170626
https://crash-stats.mozilla.com/report/index/cdeb48c2-1802-43f9-909b-35bfd0170626

Here it is Graphics section from about:support:
https://pastebin.mozilla.org/9025854

Please note that I have no extensions installed. The pages are almost loaded and then I see the crash. Not all websites give a crash, sometimes the crash appears just by closing a tab or switching to another tab.



Actual results:

Like the Firefox build of the distro, the build from Mozilla website showed the same crash.
By disabling the hardware acceleration, I got no positive results.
The tips from the support pages did not help.
In safe mode the crashes disappeared. However, there was a huge lag.




Expected results:

I was excepting that by disabling the HWA everything should work, taking into consideration there are no extensions installed. Safe mode disables the HWA and extensions, correct?

Comment 1

[Vlad Godoroja]

*excepting => expecting

Comment 2

[Emilio Cobos Álvarez (:emilio)]

All the crashes seem to come from WebGL code. Does disabling WebGL prevent the crashes?

Comment 3

[Vlad Godoroja]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> All the crashes seem to come from WebGL code. Does disabling WebGL prevent
> the crashes?

Nice, no crashes with WebGL disabled.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

(In reply to Vlad Godoroja from comment #3)
> (In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> > All the crashes seem to come from WebGL code. Does disabling WebGL prevent
> > the crashes?
> 
> Nice, no crashes with WebGL disabled.

Hmm... Smells like a driver bug off-hand. I guess it'd be nice to know the pages you open when the browser crashes, to see if someone can repro, or it rings any bell to anyone.

Comment 5

[Vlad Godoroja]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #4)
> (In reply to Vlad Godoroja from comment #3)
> > (In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> > > All the crashes seem to come from WebGL code. Does disabling WebGL prevent
> > > the crashes?
> > 
> > Nice, no crashes with WebGL disabled.
> 
> Hmm... Smells like a driver bug off-hand. I guess it'd be nice to know the
> pages you open when the browser crashes, to see if someone can repro, or it
> rings any bell to anyone.

I tested 2 sites, fiverr.com and upwork.com, and I get crashes with WebGL enabled. I remember having popup messages on fiverr.com saying something about WebGL (1-2 years ago), but the new updates fixed the problem. As I said, sometimes it crashes just by closing a tab, switching to another tab, or open a new tab. If one of 5 tabs crashes, the other 4 crash as well.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Why is HTMLCanvasElementBinding::toDataURL getting called on closing or switching tabs?  And why are we getting into the WebGLContext::GetInputStream call?

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

(In reply to Milan Sreckovic [:milan] from comment #6)
> Why is HTMLCanvasElementBinding::toDataURL getting called on closing or
> switching tabs?  And why are we getting into the
> WebGLContext::GetInputStream call?

The first question is the answer to the second at least. HTMLCanvasElementBinding::toDataURL requires the canvas data encoded as an image with the given format. It uses ImageEncoder to do this; WebGLContext implements nsICanvasRenderingContextInternal, and for objects of that type, ImageEncoder will just delegate to nsICanvasRenderingContextInternal::GetInputStream to do the encoding. (It would eventually reach back into ImageEncoder::GetInputStream to do the actual encoding of the raw data buffer.)

Looks like something in JS is listening to the OfflineAudioCompletionEvent dispatched for an AudioContext (mozilla::dom::OfflineDestinationNodeEngine::OnCompleteTask::Run in the stack trace). From there it does the toDataURL call. It may be doing this continuously but it only fails sometimes?

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Jeff suggested that there is a better alternative to WebGLContext::GetInputStream in this case; if that's the case, let's open a bug for making that change.

For the second part; there may be a legitimate reason for this, but it sounds like it's the page that's doing something "special", so perhaps there is also a tech evangelism issue here?

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.