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

UNCONFIRMED
Unassigned

Status

()

Core
Canvas: WebGL
P3
normal
UNCONFIRMED
5 months ago
2 months ago

People

(Reporter: Vlad Godoroja, Unassigned)

Tracking

54 Branch
Points:
---

Firefox Tracking Flags

(firefox55 wontfix, firefox56 wontfix, firefox57 fix-optional)

Details

(Whiteboard: [gfx-noted], crash signature)

(Reporter)

Description

5 months ago
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?
(Reporter)

Comment 1

5 months ago
*excepting => expecting
Crash Signature: [@ r300_dri.so@0x5f264a ]
Component: Untriaged → Untriaged
Product: Firefox → Core
Summary: crashes when loading pages or just switching or closing tabs → Crash in [@ r300_dri.so@0x5f264a ] - crashes when loading pages or just switching or closing tabs
Component: Untriaged → Graphics
All the crashes seem to come from WebGL code. Does disabling WebGL prevent the crashes?
(Reporter)

Comment 3

5 months ago
(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.
(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.
Component: Graphics → Canvas: WebGL
(Reporter)

Comment 5

5 months ago
(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.
Why is HTMLCanvasElementBinding::toDataURL getting called on closing or switching tabs?  And why are we getting into the WebGLContext::GetInputStream call?
Whiteboard: [gfx-noted]
Flags: needinfo?(jgilbert)
Flags: needinfo?(aosmond)
(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?
Flags: needinfo?(aosmond)
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?
Priority: -- → P3
status-firefox55: --- → wontfix
status-firefox56: --- → wontfix
status-firefox57: --- → fix-optional
Flags: needinfo?(jgilbert)
You need to log in before you can comment on or make changes to this bug.