Bug 107660 - [regression] Firefox crashes on any WebGL usage with latest libdrm
Summary: [regression] Firefox crashes on any WebGL usage with latest libdrm
Status: RESOLVED DUPLICATE of bug 107516
Alias: None
Product: DRI
Classification: Unclassified
Component: libdrm (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2018-08-22 16:36 UTC by Kai
Modified: 2018-08-22 17:03 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Kai 2018-08-22 16:36:10 UTC
I recently noticed, that tabs in Firefox (Debian package 61.0.1-1 and 61.0.2 from mozilla.org) started crashing on WebGL usage. The easiest trigger is to just visit https://maps.gogle.com/

Since I was pointed towards bug 107384, comment #6 on IRC by Michel Dänzer and I see the loader errors as he described on IRC, I'm assuming this is related. I can't be 100 % sure, because I'm unable to get a proper backtrace from Firefox (see below). It doesn't seem to be the same issue though, because using a libdrm built from Git (f31fd57c60) doesn't fix the crashes for me.

I tried attaching GDB to the content process by launching firefox with:
 $ MOZ_DEBUG_CHILD_PROCESS=1 firefox -safe-mode
and then running
 # gdb /usr/lib/firefox/firefox $PID
where $PID is replaced by the actual PID of the tab process, which firefox prints on the console when started with MOZ_DEBUG_CHILD_PROCESS=1. The attaching seems to run fine, gdb is loading a bunch of debug information for all the libraries and Firefox itself. But when I continue from the (gdb) prompt, I immediately run into an endless stream of SIGSYS errors like
> Thread 1 "Web Content" received signal SIGSYS, Bad system call.
> 0x00007f884b08b397 in __access (file=0x7f88370b3360 "/usr/share/gtk-3.0/settings.ini", type=type@entry=0) at ../sysdeps/unix/sysv/linux/access.c:27
> 27      ../sysdeps/unix/sysv/linux/access.c: No such file or directory.
Probably the sandbox that prevents this? Sadly I haven't found a way around that yet. (Any pointers welcome. Maybe it's possible to instrument libdrm/radeonsi/… in a way, that helpful information can be dumped somewhere, when the tab crashes.)

Without GDB the tab just crashes and offers to be closed or reloaded. In the terminal window where I started Firefox (with a clean profile and in safe mode) I get the following error:
> libGL error: MESA-LOADER: failed to retrieve device information
> libGL error: unable to load driver: amdgpu_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: amdgpu
> libGL error: MESA-LOADER: failed to retrieve device information
> libGL error: unable to load driver: amdgpu_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: amdgpu
> [Parent 20860, Gecko_IOThread] WARNING: pipe error (47): Connection reset by peer: file /build/firefox-tG9MzV/firefox-61.0.1/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
> [Parent 20860, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /build/firefox-tG9MzV/firefox-61.0.1/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709
> 
> ###!!! [Parent][MessageChannel] Error: (msgtype=0x160068,name=PBrowser::Msg_SynthMouseMoveEvent) Channel error: cannot send/recv
> 
> 
> ###!!! [Parent][MessageChannel] Error: (msgtype=0x16007F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

The graphics stack I used (fully updated Debian testing as a base) for testing is:
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/5fab32ddad
libdrm: Git:master/f31fd57c60
LLVM: SVN:trunk/r340334 (8.0 devel)
X.Org: 2:1.20.0-3
Linux: 4.18.3
Firmware (firmware-amd-graphics): 20180518-1
libclc: Git:master/62a9191b60
DDX (xserver-xorg-video-amdgpu): 18.0.1-1+b1

Let me know, if you need anything else.
Comment 1 Michel Dänzer 2018-08-22 17:03:03 UTC

*** This bug has been marked as a duplicate of bug 107516 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.