Bug 109927

Summary: Xorg segfault when a web browser is opened
Product: Mesa Reporter: keiron.davies
Component: OtherAssignee: mesa-dev
Status: RESOLVED MOVED QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: massabnaeem160
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
i915 platform: i915 features:
Attachments: Output of journalctl -b
/home/usernaym/.local/share/xorg/Xorg.0.log.old & Xorg.0.log

Description keiron.davies 2019-03-07 16:47:26 UTC
Created attachment 143574 [details]
Output of journalctl -b

I use the Padoka PPA. Approximately 45 hours ago, there was an update for Bionic that moved the Mesa version from 'master git branch up to commit 6fa923a65daf1ee73c5cc763ade91abc82da7085' to commit 43f40dc7cb234e007fe612b67cc765288ddf0533, and xserver-xorg-video-amdgpu from 'master git branch up to commit 9045fb310f88780e250e60b80431ca153330e61b' to commit a2b32e72fdaff3007a79b84929997d8176c2d512. No other changes have taken place in my system.

Since then, within 1.5s of opening a web browser (Firefox, Chromium), I get a crash to graphical login prompt. I can open the Nautilus file browser, even a terminal session with transparency enabled, without issue for as long as I like. Below is the error message and my system specs, and attached are the relevant logfiles from a Chromium crash. Firefox crash produces no specific error messages prior to the segfault, but I can upload those logs too if needed. Apologies if this bug is incorrectly filed, I wasn't sure whether the issue may lie with mesa or xserver-xorg-video-amdgpu.

Mar 07 15:35:07 host chromium-browser.desktop[3259]: [3293:3293:0307/153507.139737:ERROR:sandbox_linux.cc(364)] InitializeSandbox() called with multiple threads in process gpu-process.
Mar 07 15:35:07 host gnome-keyring-daemon[1895]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
Mar 07 15:35:07 host gnome-keyring-daemon[1895]: asked to register item /org/freedesktop/secrets/collection/Default_5fkeyring/1, but it's already registered
Mar 07 15:35:07 host gnome-keyring-daemon[1895]: asked to register item /org/freedesktop/secrets/collection/Default_5fkeyring/1, but it's already registered
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE)
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Backtrace:
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x5558457998cd]
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) 1: /usr/lib/xorg/Xorg (0x5558455e1000+0x1bc669) [0x55584579d669]
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ffb48abe000+0x12890) [0x7ffb48ad0890]
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE)
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Segmentation fault at address 0x0
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE)
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: Fatal server error:
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Caught signal 11 (Segmentation fault). Server aborting
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE)
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: Please consult the The X.Org Foundation support
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]:          at http://wiki.x.org
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]:  for help.
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE) Please also check the log file at "/home/usernaym/.local/share/xorg/Xorg.0.log" for additional information.
Mar 07 15:35:10 host /usr/lib/gdm3/gdm-x-session[1899]: (EE)

System:    Host: host Kernel: 5.0.0-050000-generic x86_64 bits: 64 Desktop: Gnome 3.28.3
           Distro: Ubuntu 18.04.2 LTS
Machine:   Device: desktop Mobo: ASUSTeK model: M4A87TD EVO v: Rev 1.xx serial: N/A
           BIOS: American Megatrends v: 2001 date: 03/08/2011
CPU:       Quad core AMD Phenom II X4 970
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Hawaii PRO [Radeon R9 290/390]
           Display Server: x11 (X.Org 1.19.6 ) drivers: ati,vesa (unloaded: modesetting,fbdev,radeon)
           Resolution: 2560x1440@59.95hz
           OpenGL: renderer: AMD Radeon R9 390 Series (HAWAII, DRM 3.27.0, 5.0.0-050000-generic, LLVM 9.0.0)
           version: 4.5 Mesa 19.1.0-devel - padoka PPA
Comment 1 keiron.davies 2019-03-07 16:49:41 UTC
Created attachment 143575 [details]
/home/usernaym/.local/share/xorg/Xorg.0.log.old & Xorg.0.log

Here are the Xorg logs from the same Chromium crash.
Comment 2 Michel Dänzer 2019-03-07 17:59:43 UTC
Can you isolate whether it was the Mesa or xserver-xorg-video-amdgpu update that triggered it?
Comment 3 keiron.davies 2019-03-07 18:37:27 UTC
(In reply to Michel Dänzer from comment #2)
> Can you isolate whether it was the Mesa or xserver-xorg-video-amdgpu update
> that triggered it?

I'm not sure how I'd roll back either one, the PPA no longer has the old packages (I'll see if they're cached on disk). The only way I can conceive of is building them from git myself, but I suppose I'd have to be careful to use the same build options as the PPA (libs, llvm 9.0 etc.) Can you suggest which would be easier to build? There are a relatively small number of accepted commits between the updates, bisection should be possible, it's just not something I've ever done before.

I've confirmed the same behaviour with kernel 4.20, just to make sure it wasn't a 5.0 bug that didn't present itself for a few days. Also, setting amdgpu.dc=1 as a kernel command line parameter allows me to launch Firefox and navigate here but then the same crash occurs when I interact with a dropdown menu. No difference in log output.
Comment 4 keiron.davies 2019-03-07 21:21:24 UTC
I found that the previously built .debs were available on launchpad, so I reverted packages to isolate. After rolling back xserver-xorg-video-amdgpu to the previously working version and rebooting there was no change to the problem behaviour. Next I reverted the updates to Mesa, where I ended up in dependency hell for not paying proper attention. After using my /var/log/apt/history.log to figure out which packages I needed, I made corrections, rebooted, and the problem behaviour is gone. So this change does seem to be located in Mesa after commit 6fa923a65daf1ee73c5cc763ade91abc82da7085.

I will update xserver-xorg-video-amdgpu alone and see if that makes any change, but I doubt it.
Comment 5 Michel Dänzer 2019-03-08 08:00:02 UTC
Weirdly, the backtrace of the crash doesn't look directly related to Mesa.

Maybe there's memory corruption, in which case running Xorg in valgrind might give a clue. (Make sure debugging symbols are available for /usr/lib/xorg/Xorg and radeonsi_dri.so at least)

Other than that, bisecting Mesa is probably the best way to make progress.
Comment 6 fin4478 2019-03-11 04:36:22 UTC Comment hidden (spam)
Comment 7 keiron.davies 2019-03-11 09:51:59 UTC
(In reply to fin4478 from comment #6)
> >  Display Server: x11 (X.Org 1.19.6 ) drivers: ati,vesa
> You should use the radeon or amdgpu kernel driver with a Hawaii card. Update
> to ubuntu cosmic. See:
> https://wiki.archlinux.org/index.php/
> AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support

A cursory glance at the attached journald logs would reveal I am booting with kernel parameters 'radeon.cik_support=0 amdgpu.cik_support=1', have blacklisted radeon, and am running AMDGPU (unless I am very much mistaken).
lspci -k reports:
05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290/390] (rev 80)
	Subsystem: ASUSTeK Computer Inc. STRIX R9 390
	Kernel driver in use: amdgpu
	Kernel modules: radeon, amdgpu

As for bisecting this issue - building Mesa is a little overwhelming for me and I haven't been able to find a comprehensible and up to date guide for my distro in my spare time. I can figure out how to install build dependencies, but the sheer number of compile time options is perplexing. There's a good start in the PPA buildlog for the package, but parsing and understanding it is slow.
Once I've built it, would it make more sense to try to generate .debs and install it all, or somehow run the system with this version installed to /opt?
Comment 8 Michel Dänzer 2019-03-11 10:54:17 UTC
(In reply to keiron.davies from comment #7)
> Once I've built it, would it make more sense to try to generate .debs and
> install it all, or somehow run the system with this version installed to
> /opt?

The former, otherwise it may not get picked up for everything by the Xorg process.
Comment 9 GitLab Migration User 2019-09-18 20:19:14 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/935.

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.