Closed
Bug 1277981
Opened 9 years ago
Closed 2 years ago
Loading a specific page in Firefox crashes the X server
Categories
(Core :: Graphics: CanvasWebGL, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: botond, Unassigned)
References
()
Details
(Whiteboard: [gfx-noted])
Attachments
(1 file)
2.95 KB,
text/plain
|
Details |
I'm running Debian stable with the KDE desktop envionment.
STR:
Load http://taccgl.org/blog/HTMLpages-with-3D-objects.html in Nightly
My entire desktop environment freezes and becomes nonresponsive. Within a minute or so, the graphical environment goes away completely and I'm dropped to a shell. I assume this means the X server crashed.
Let me know what other info I can provide to diagnose the issue.
Comment 1•9 years ago
|
||
Can you paste the Graphics section of about:support?
Flags: needinfo?(botond)
Updated•9 years ago
|
Whiteboard: [gfx-noted]
Reporter | ||
Comment 2•9 years ago
|
||
Graphics
--------
Features
Compositing: OpenGL
Asynchronous Pan/Zoom: wheel input enabled; scrollbar drag enabled
WebGL Renderer: nouveau -- Gallium 0.4 on NVC1
Hardware H264 Decoding: No
GPU #1
Active: Yes
Description: nouveau -- Gallium 0.4 on NVC1
Vendor ID: nouveau
Device ID: Gallium 0.4 on NVC1
Driver Version: 3.0 Mesa 10.3.2
Diagnostics
AzureCanvasAccelerated: 0
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
CairoUseXRender: 0
Decision Log
HW_COMPOSITING:
blocked by default: Acceleration blocked by platform
force_enabled by user: Force-enabled by pref
Flags: needinfo?(botond)
Comment 3•9 years ago
|
||
Of particular note is that you have layers accelerations enabled, and you are using nouveau and a somewhat old version of Mesa.
Can you try upgrading Mesa to 11 and the associated DRM stuff? If not that, do you have some way to try running with another driver than nouveau, either Mesa/Intel or nvidia proprietary?
At least for me with nvidia proprietary, it seems to run fine, though I am using the same version of Mesa as you.
Milan, can you forward this around to any appropriate gfx people who could test with alternate drivers, or if they use nouveau as well, confirm it?
Flags: needinfo?(milan)
Reporter | ||
Comment 4•9 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #3)
> Can you try upgrading Mesa to 11 and the associated DRM stuff? If not that,
> do you have some way to try running with another driver than nouveau, either
> Mesa/Intel or nvidia proprietary?
ni?myself until I'm back in the office and can answer these.
Flags: needinfo?(botond)
Comment 5•9 years ago
|
||
Check /var/log/kdm.log and /var/log/Xorg.0.log.old for a crash stack.
Updated•9 years ago
|
Blocks: ogl-linux-beta
Flags: needinfo?(milan)
Reporter | ||
Comment 6•9 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #3)
> Of particular note is that you have layers accelerations enabled, and you
> are using nouveau and a somewhat old version of Mesa.
>
> Can you try upgrading Mesa to 11 and the associated DRM stuff?
Andrew and I played around with this for a bit.
Upgrading to Mesa 11 made the "takes the whole display server down" issue go away. However, Firefox's behaviour on the page was still bad. Specifically, we were seeing rendering artifacts (black boxes over portions of the page), and sometimes the content process would hang.
This latter event (content process hanging) is accompanied by the following output on stdout:
nouveau: kernel rejected pushbuf: Cannot allocate memory
followed by a long list of hex values, and things like the following in dmesg:
[2846668.956091] nouveau E[ PFIFO][0000:01:00.0] write fault at 0x0000bcf000 [PAGE_NOT_PRESENT] from PGRAPH/GPC0/PROP on channel 0x001f882000 [Web Content[22689]]
[2846668.956098] nouveau E[ PFIFO][0000:01:00.0] PGRAPH engine fault on channel 8, recovering...
Playing around with it a bit, we made a few observations:
- The behaviour is independent of whether the compositor uses hardware acceleration.
Rather, it's the content process' use of WebGL that's problematic.
- The behaviour is independent of e10s. Disabling e10s just causes the entire
Firefox process to hang. This further supports the theory that the priblem is
triggered by WebGL.
- The behaviour is dependent on the size of the Firefox window. Resize it to be
small enough, and things work fine.
- Running Firefox under apitrace revealed that we're binding a 2048x2048 texture,
suggesting that we're running into a maximum texture size limit (as Firefox
limits texture sizes to one half of the limit reported by Mesa, which is
4096x4096).
Hopefully that's enough to give us something to go on / guide further investigation.
> If not that,
> do you have some way to try running with another driver than nouveau, either
> Mesa/Intel or nvidia proprietary?
On a different machine with Intel integrated graphics, there are no rendering artifacts or hangs, but some of the animations do not render at all, and are replaced by static images instead. (Possibly this is a sign of the webpage querying something and falling back to something.)
I haven't tried the nvidia proprietary driver. If that can still provide valuable information, I can try it.
Flags: needinfo?(botond)
Reporter | ||
Comment 7•9 years ago
|
||
Here's a more complete fragment of output from dmesg when we were seeing the hang.
Comment 8•9 years ago
|
||
As we've confirmed that this is a WebGL issue, I'm unblocking shipping GL layers on Linux.
No longer blocks: ogl-linux-beta
Reporter | ||
Comment 9•9 years ago
|
||
One more piece of info: with Chromium running on the same system (with nouveau), I see the same rendering artifacts as in Firefox, but it manages to avoid the kernel errors and the associated hang.
Updated•8 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
Updated•2 years ago
|
Component: Graphics → Graphics: CanvasWebGL
Updated•2 years ago
|
Updated•2 years ago
|
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•