I get the same issue on Arch, running the steam-native bin. On exit, the Xorg process shoots up to 100% utilization, and the last few lines in steam's console window are:
Refresh rate: 1
Refresh rate: 0
Refresh rate: 0
<repeated a bunch>
Refresh rate: 60
Refresh rate: 60
<repeated a bunch>
Refresh rate: 0
Refresh rate: 0
<repeated a bunch>
Refresh rate: 60
Refresh rate: 60
<repeated a bunch>
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
And steam just hangs.
Same issue on Linux Mint 18.3 (Ubuntu 16.04 LTS).
Same problem on Debian 9, but not sure what causes this issue. It does not always happen.
What do you people usually do before this happens? Any specific activity?
What do you people usually do before this happens? Any specific activity?
Nothing that stands out. Sometimes I've played a few games here and there and there, but I'm not certain that I always have when experiencing this. I've definitely used Steam's chat functionality, and likely have downloaded updates and/or switched to beta branches (have tried jumping around branches, but that doesn't seem to trigger a problem in the short term at least).
The trouble with something that seems to manifest over such a long period of time is that I'm also using my computer for normal work while Steam is open - narrowing down a specific action or application that might be playing a role is hard.
The only thing I do within Steam before the problem occurs is playing Dota 2.
Yep, same here on Solus. It seems inconsistent. Sometimes occurs even if there are hours between the last game session and attempting to close Steam.
I'm not able to reproduce this on my end after letting Steam run for a long time and running/downloading games so far. For someone that is able to reproduce this pretty often, would it be possible to trigger the situation where Steam is unresponsive/busy during shutdown, and kill it with SIGBUS while it's in the middle of doing that? That would generate a .dmp file that would let us see what it's doing if attached here.
Haven't seen this happen for a few days that I've now autostarted steam. I'm guessing some patch to some program around 20 days ago fixed it.
It still happens for me. Seems like the longer Steam has been open, the longer it lags on exit. I had it open for ~30 hours and tried to get the dump, but the freeze only lasted ~30 seconds. I'll try again after leaving it open for a few days.
It puts a massive load on Xorg which uses 100% CPU until Steam exits. True, it's incosistent. For me it usually happens after playing Natural Selection 2 for several hours in the evening. I opened htop in terminal and looked at the processes, the terminal doesn't freeze and I could see that Xorg consumes an enormous amount of CPU time. Still, nothing interesting in the system or Xorg's logs. A random guess would be that Steam allocates a lot of X resources like bitmaps and it takes time to free them on exit.
What does xrestop report for you after Steam has been running for a long time?
OK, I ran xrestop before attempting to exit steam:
res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
3200000 50 1 1 1 141 0B 5K 5K ? Friends
3400000 7 26 0 1 14 4B 1K 1K 22036 Steam
Nothing seemed out of the ordinary there. Then I exited steam from the UI, confirmed I was in the frozen state, and sent SIGBUS. Steam outputted the following:
...
Refresh rate: 60
Refresh rate: 60
Refresh rate: 60
Refresh rate: 60
crash_20180124210626_1.dmp[18978]: Uploading dump (out-of-process)
/tmp/dumps/crash_20180124210626_1.dmp
crash_20180124210626_1.dmp[18978]: Finished uploading minidump (out-of-process): success = yes
crash_20180124210626_1.dmp[18978]: response: CrashID=bp-991ab573-0bb4-4c9f-8e53-6b7152180125
crash_20180124210626_1.dmp[18978]: file ''/tmp/dumps/crash_20180124210626_1.dmp'', upload yes: ''CrashID=bp-991ab573-0bb4-4c9f-8e53-6b7152180125''
/home/sean/.local/share/Steam/steam.sh: line 927: 22036 Bus error (core dumped) $STEAM_DEBUGGER "$STEAMROOT/$STEAMEXEPATH" "$@"
The gdb backtrace of the dump looked like this:
(gdb) bt
#0 0xf7f2bdb9 in __kernel_vsyscall ()
#1 0xf7a05493 in poll () from /usr/lib32/libc.so.6
#2 0xf78fad23 in ?? () from /usr/lib32/libxcb.so.1
#3 0xf78fb35c in ?? () from /usr/lib32/libxcb.so.1
#4 0xf78f8989 in ?? () from /usr/lib32/libxcb.so.1
#5 0xf78fa69d in ?? () from /usr/lib32/libxcb.so.1
#6 0xf78fa864 in xcb_wait_for_reply64 () from /usr/lib32/libxcb.so.1
#7 0xf7d92d19 in _XReply () from /usr/lib32/libX11.so.6
#8 0xf7d8e46f in XSync () from /usr/lib32/libX11.so.6
#9 0xf7d6f515 in XCloseDisplay () from /usr/lib32/libX11.so.6
[#10](/issue/ValveSoftware/steam-for-linux/10) 0xf198dfc1 in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/libSDL2-2.0.so.0
[#11](/issue/ValveSoftware/steam-for-linux/11) 0xf1956cfa in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/libSDL2-2.0.so.0
[#12](/issue/ValveSoftware/steam-for-linux/12) 0xf18c579f in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/libSDL2-2.0.so.0
[#13](/issue/ValveSoftware/steam-for-linux/13) 0xf18d7cf9 in SDL_QuitSubSystem () from /home/sean/.local/share/Steam/ubuntu12_32/libSDL2-2.0.so.0
[#14](/issue/ValveSoftware/steam-for-linux/14) 0xf2b43c87 in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/steamui.so
[#15](/issue/ValveSoftware/steam-for-linux/15) 0xf2b4409c in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/steamui.so
[#16](/issue/ValveSoftware/steam-for-linux/16) 0xf2b27355 in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/steamui.so
[#17](/issue/ValveSoftware/steam-for-linux/17) 0xf305a270 in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/steamui.so
[#18](/issue/ValveSoftware/steam-for-linux/18) 0xefc02cad in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/vgui2_s.so
[#19](/issue/ValveSoftware/steam-for-linux/19) 0xf2fb3f9a in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/steamui.so
[#20](/issue/ValveSoftware/steam-for-linux/20) 0xf2fbaa88 in ?? () from /home/sean/.local/share/Steam/ubuntu12_32/steamui.so
[#21](/issue/ValveSoftware/steam-for-linux/21) 0x56598bd0 in RunSteam(int, char**, bool) ()
[#22](/issue/ValveSoftware/steam-for-linux/22) 0x56599b0b in ?? ()
[#23](/issue/ValveSoftware/steam-for-linux/23) 0x56584dec in ?? ()
[#24](/issue/ValveSoftware/steam-for-linux/24) 0xf7931793 in __libc_start_main () from /usr/lib32/libc.so.6
[#25](/issue/ValveSoftware/steam-for-linux/25) 0x56588681 in _start ()
And I can upload the actual dump file if needed. Thanks for taking a look at this, @Plagman
Also:
[sean@coach ~]$ /usr/lib/xorg-server/Xorg -version
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.71-1-lts x86_64
Current Operating System: Linux coach 4.14.13-1-ARCH #1 SMP PREEMPT Wed Jan 10 11:14:50 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=386f5eab-ae6f-48fd-8b27-1aaa50edc521 rw quiet
Build Date: 25 December 2017 02:02:38PM
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[sean@coach ~]$ pacman -Qi nvidia | grep Version
Version : 387.34-19
xrestop output (removed unrelated processes):
res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
1200000 15 3 1 8 66 18814K 2K 18817K 21101 Terminal
0800000 11 2 1 2 1011 18167K 25K 18192K 1520 awesome
3200000 50 2 1 1 76 0B 4K 4K ? Steam
3800000 4 25 0 1 12 4B 984B 988B 740 Steam
There was a lag at Steam exit but not as significant as usual (I played just a bit today), killall -BUS steam couldn't find the process, should've used pkill. Will try SIGBUS tomorrow then.
The process name is "Steam" (capital S). You can also just use the PID that xrestop lists (740 in your example) like:
kill -SIGBUS 740
Thanks for the backtrace, that's helpful. Getting more samples would be great, as it could be performing multiple operations during shutdown.
I tried both "steam" and "Steam", killall couldn't find the process, probably because it has a full path in its name and I've installed Steam to /opt. pkill worked fine on a newly started Steam so I'll try it later today.
I've done it two more times on my machine, the backtrace has been identical each time. I've been opted in to the Steam client beta this whole time if that makes any difference.
Here's a crashdump of Steam freezing Xorg/Awesome WM.
For reference, the attached minidump is a SIGBUS in linux-gate.so in a steamui.so thread.
Another dump I'm slightly more confident of (checked for the freeze and ran pkill -BUS steam from the phone via ssh): crash.zip
Have you all tried the Steam Beta Client update the released on Jan 26th? It had a Linux-specific fix with shutdowns, I wonder if any work on that helped with this?
I'm always at Steam Beta and I saw the release notes about that fix, didn't help, unfortunately.
Getting this too on Arch, NVIDIA Proprietary drivers
Took a long brake from dota but now after coming back to it the lag happens again. Here's a crash dump of pkill -BUS steam
I got new info: After having long sessions of Dota, the shutdowns become worse each time and the problems persists for several shutdowns even after stopping playing Dota. For me after enduring about 1-2 weeks of forcibly shutting down steam the problem disappears. I'm willing to bet the problem comes back once I start playing Dota again.
New Steam Beta update fixed it for me.
Same here.
On exit, the Xorg process shoots up to 100% utilization.
$ lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description: Linux Mint 18.3 Sylvia
Release: 18.3
Codename: sylvia
Update: Beta client didn't fix anything, the lag was gone for 2 sessions then it came back. Interestingly, the mouse pointer's position gets locked in the screen even though you can move it, but can't click anything. Keyboard inputs are working normally. Maybe it's a problem with the mouse drivers?
@LDD19 I have a strong feeling that's just because the mouse is a hardware mouse. I'm willing to bet that if you turned on software mouse, the pointer wouldn't move one bit
@LDD19 It's not like that for me. Previously, after having Steam open for a long time before closing it, the cursor appeared stutter-y and I could hardly click on anything or even focus other windows when cursor was over them. Moving the mouse to the nearest terminal and typing in pkill -9 steam was a real challenge.
Now the cursor itself appears to move smoothly, yet all other effects still persist.
I'll take the beta for a spin and see if it fixes anything.
EDIT: The beta does not fix anything.
I've also noticed that when Steam client is open, the amount of memory Xorg allocates is abnormally high, and keeps rising over time. When the client is closed however the memory usage instantly drops down to nominal levels.
OK, given past unsuccessful attempts on our end to rootcause this within Steam, it might be worth to take a step back and try to find more general configuration patterns for affected users. Can people affected by this issue post their X server version (through eg. sudo Xorg -version) and what desktop environment/compositor they're using?
Thanks again @Plagman for the attention to this.
[sean@coach ~]$ s Xorg -version
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.15.6-1-ARCH x86_64
Current Operating System: Linux coach 4.16.4-1-ARCH #1 SMP PREEMPT Tue Apr 24 13:21:29 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=386f5eab-ae6f-48fd-8b27-1aaa50edc521 rw quiet
Build Date: 12 April 2018 05:31:07AM
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[sean@coach ~]$ awesome -v
awesome v4.2 (Human after all)
• Compiled against Lua 5.3.4 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.5
• LGI version: 0.9.2
Been running the Steam beta depot, and I use the "steam-native" launcher.
Same Xorg build as above, also running Steam beta and using steam-native launcher (currently trying out the regular launcher, will report how it went in a later edit. EDIT: the bug still happens when I use the regular launcher).
Also:
$ i3 -v
i3 version 4.15-15-gc0bcd371 (2018-03-11, branch "next") © 2009 Michael Stapelberg and contributors
$ compton --version
git-v0.1_beta2-87-g316eac0-2017-04-30
I'm running Xorg and awesome (without any compositor like compton). Info:
Xorg -version
This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.
X.Org X Server 1.19.99.904 (1.20.0 RC 4)
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.16.0-gentoo x86_64 Gentoo
Current Operating System: Linux DarkRain 4.16.3-gentoo #1 SMP PREEMPT Mon Apr 23 18:16:48 CEST 2018 x86_64
Kernel command line: BOOT_IMAGE=/kernel-4.16.0-gentoo root=/dev/sda3 ro
Build Date: 16 April 2018 06:02:26PM
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
awesome --version
awesome v4.2 (Human after all)
• Compiled against Lua 5.1.5 (running with Lua 5.1)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.6
• LGI version: 0.9.0
I should note that it seems to matter what games has been played for it to get really bad.
For example, if I play 3 hours of Dota2, it will freeze my computer for around 2-3min when I close steam.
However, if I play Hollow Knight or most of my other games for 3 hours and then try to close steam, it is not nearly as bad as with Dota2. My system will still freeze but only for a few seconds.
So now when I have been playing dota, I usually just kill steam instead to avoid the freezes.
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-5-amd64 x86_64 Debian
Current Operating System: Linux at46-desktop 4.15.0-3-amd64 #1 SMP Debian 4.15.17-1 (2018-04-19) x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.15.0-3-amd64 root=/dev/mapper/vgdeb-root ro quiet splash
Build Date: 26 January 2018 04:30:21PM
xorg-server 2:1.19.6-1 (https://www.debian.org/support)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Xfce desktop on Debian testing and I don't opt in Steam beta
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-119-generic x86_64 Ubuntu
Current Operating System: Linux kiroma-X550JX 4.15.0-20-generic [#21](/issue/ValveSoftware/steam-for-linux/21)-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=dc52134f-1748-421d-a9ac-3037ed3ceabb ro quiet splash vt.handoff=1
Build Date: 13 April 2018 08:07:36PM
xorg-server 2:1.19.6-1ubuntu4 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
With display manager: sddm 0.17.0
Desktop environment: KDE
Compositor: KWin 5.12.4
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-5-amd64 x86_64 Debian
Current Operating System: Linux homecomp 4.15.8-rkfg #5 SMP PREEMPT Sat Mar 10 19:12:24 MSK 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.8-rkfg root=UUID=65f2a938-d8f1-45cc-848e-c31da4135a5a ro quiet
Build Date: 26 January 2018 04:30:21PM
xorg-server 2:1.19.6-1 (https://www.debian.org/support)
Current version of pixman: 0.34.0
awesome v3.5.6 (For Those About To Rock)
• Build: Jun 5 2015 06:28:50 for x86_64 by gcc version 4.9.2 (root@minjo)
• Compiled against Lua 5.1.5 (running with Lua 5.1)
• D-Bus support: ✔I confirm that Xorg memory goes way up until I exit Steam. I don't know how fast it grows while I play though.
After I played NS2 for a couple of hours and closed the game, Steam is still running:
UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
root 1039 1003 1 122142 281556 1 Apr29 tty7 00:05:53 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
rkfg 22739 22562 4 111535 202112 6 Apr29 ? 00:05:47 /opt/SteamLinux/ubuntu12_32/steam
rkfg 22743 22739 0 34943 49580 6 Apr29 ? 00:00:00 /opt/SteamLinux/ubuntu12_32/steam
After closing Steam (Xorg experiences freezes for 5-10 seconds):
UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
root 1039 1003 1 77534 103128 5 Apr29 tty7 00:05:59 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
So, Steam indeed allocates a lot of memory inside Xorg process and it's getting released afterwards and Xorg lags significantly during the process.
I did more testing and found out that the amount of lag is proportional to the game ID the Steam process is running on. I tried opening the Steam app instead of directly opening the game shortcut and the lag was only a few seconds this time.
The thing is that when you try to open a game from a launcher shortcut the Steam process will also be marked as the app ID of the same game. Instead of being marked as Steam-Steam, it will be something like Steam-Steam:://rungameid/570 (for Dota2 in this case) even after you close the game.
Interesting; are other people affected by this also running Steam through running a game, rather than just starting the Steam app by itself?
I'm always starting steam and then the game I wanna play through the steam library and the duration of the lag varies between a few seconds and about one minute (only if steam was open the whole day).
I'm always starting the games by starting them via the steam app. But I still get really severe freezes when closing. So I do not think it is related.
I've never started Steam through a game shortcut, I always just run the steam command. The longer I had Steam open, the longer the lag (doesn't matter if I started games during that time or never touched the client once).
I always start steam (alt+F2>steam) then launch a game. I got a 15 minutes lock after the recent steam beta update (I waited it out).
Currently running on devuan (systemd-less) machine.
X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-4-amd64 x86_64 Debian
Current Operating System: Linux Aasterinian 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 root=UUID=c8a042b6-0e7a-4bc8-9674-ce99567bb6fa ro quiet
Build Date: 16 October 2017 08:19:45AM
xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
DE:
MATE Desktop Environment 1.16.2
compton 0.1~beta2+20150922
The lag time seems to be related to the length of time that Steam was running. I tend to leave Steam up more-or-less permanently, and now I just went to restart it, and it pegged the CPU long enough for me to decide to investigate the problem on the laptop, and find and completely read through this thread. Probably at least 15 mins of lag so far. The GUI is no longer completely unresponsive, even though Xorg is still saturating one core; this usually heralds the beginning of the end of the problem.
Debian Stretch, Xfce.
X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-4-amd64 x86_64 Debian
Current Operating System: Linux sikorsky 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-4-amd64 root=UUID=ec9c04ba-5c2b-4a67-a454-c02155296dcd ro quiet
Build Date: 16 October 2017 08:19:45AM
xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
So I'm finding that TF2 is one of the games that causes the issue to happen the fastest.
After 3 competitive matches which equals to around 1,5h of gameplay, I'm sitting at Xorg with 154MB of RAM allocated.
However this time there was no lag when closing Steam this time? This is weird.
Distro: Linux Mint 18.3 Cinnamon 64bit
I was having the same issue, especially after playing TF2, as mentioned above. Today I seemed to manage to fix it, and maybe identified the cause too. I noticed that the typical location of a Steam install on Linux is ~/.local/share/Steam, however mine was located under ~/.steam , with nothing Steam related in ~/.local/share/. I had installed Steam using the Software Manager, which seems to install it in ~/.steam by default.
Noticing this, I uninstalled Steam and TF2 and did a fresh install of Steam using the .deb provided on the official Steam download page, making sure everything was installed in ~/.local/share/Steam (it should be the default option).
That seems to have completely fixed the issue! To test I played a couple of hours of TF2, launched a bunch of diffrent games and left Steam open for a while before closing it and I haven't encountered the problem once.
This might be not due to moving Steam but rather because of reinstalling it from scratch and removing any garbage it might have accumulated in years. Mine is also not in a standart location, it's in /opt/SteamLinux (because the system root is on SSD and Steam didn't support multiple libraries back then). However, what you described partly coincides with what I experience, at work Steam is installed to the default directory and I don't have these freezes then. But I'm not playing there much, only on the lunch break which is <30 minutes. So it's hard to tell.
My Steam install was relatively fresh (<2 months), so I doubt there was much garbage there to begin with. Furthermore, I remember having this issue when I first did that install after playing Hitman.
~Another important thing that I forgot to mention: this is not the only issue I was having that now seems to be gone. In both Hitman and TF2, after playing the game for a while and switching levels/servers several times, the game's framerate would suddenly drop to around 5fps, with the only fix being a game restart.~
EDIT Nevermind, the framerate drop is still happening, might be completely unrelated.
To be 100% sure, I could install Steam in a non-default directory again and see if these issues pop up. In the meantime I'd be curious to see if everyone having this issue has Steam installed in a different directory than the default.
Just wanted to chime in and say I'm also experiencing the problem others have described...
Also it's not just when closing Steam entirely; just happened to me when closing a window that came up with an in-game screenshot...
At some point it's gonna be more productive to fly someone to Valve who's still experiencing this and test their PC out.
I volunteer @Managor ! Kappa
Just as another data point, after a day or so steam eats an entire CPU of processing power on both my 16.04 install and my wife's 18.04 install of kubuntu's.
I do have my games installed in a different disk because of space issues. The first time I noticed this problem was when I created a new directory to store my games on another SSD. Does anyone have this issue without games being installed on a different disk?
Yes, I have the issue and am using the default location and only a single hard drive.
I'm still having no luck reproducing this, having left the client running overnight, with either NVIDIA or Mesa. Can people affected try installing Xorg debug symbols and look at perf top while the high CPU usage is happening? Or record a perf log.
At this point the SIGBUS method described above won't be helpful because it's clear the issue has to do with Steam trying to close its X connection, and most of the work happening inside of Xorg itself.
@Plagman leaving the client running overnight only worsens the lag. The lag will happen after you try to close Steam after playing a game for a few hours.
This might be troublesome as there is no dbg package for Xorg on Ubuntu 18.04 apparently...
I meant to post this earlier, but a storm raged as soon as I stopped collecting the perf log. I'm not sure if it is how to do it, though. I closed steam, then switched to a tty and launched a perf record -p $(pgrep Xorg). I haven't found a package with debug symbols for xserver-xorg-core, if I understand correctly -dev is different than -dbg is it not?
perf.data.zip
Looks like for Ubuntu, an additional package repository needs to be added to get debug symbols: https://wiki.ubuntu.com/Debug Symbol Packages#Getting_-dbgsym.ddeb_packages
Yes, -dev packages contain stuff like headers for includes in a project.
-dbg packages contain special files with debug symbols that are created while an executable is created, and if the correct flag is passed to the compiler.
Also, thanks for that article, I'll try to profile Xorg when I get the chance.
Alright, after installing the dbgsym package I fired up TF2 and played for a while. When memory usage of Xorg reached ~200MB, I quit the game and recorded for a bit to measure instruction calls at idle for reference:
idle.tar.gz
Then I recorded Steam shutting down here:
quit.tar.gz
The archives contain a pref.data as well as annotate.txt and report.txt which I generated by simply running pref report > report.txt and pref annotate > annotate.txt.
I have this issue as well, but I have not played any steam games for months. I only chat, but I do that a lot. I had steam open for 24 hours now with 20+ chat tabs and and when I closed it it my high-end pc froze up for what seemed like over 5 minutes. Even Spotify playback stopped. I could only move the mouse sometimes and even then was very sluggish. UI components did not react to mouse clicks. It happens every time Steam was open for a long time and I close it. I will try to provide more technical info next time, but my memory use seems much lower than usual so I guessing it's a memory leak issue.
Edit: I am on 16.04 LTS with nvidia drivers and have no steam games installed at all.
@kiroma This is very useful; was the data recorded with '--call-graph'? If not, any chance you could try again with that option set? Sorry, should have specified upfront...
No, it wasn't. I'll try to re-do the test when I get back home in ~12 hours.
Well I got a little bit scared at the size of the data files but compression did wonders.
Idle:
idle.tar.gz
Quit:
quit.tar.gz
Perf data v2, Now with Call-Graph™!
Thanks! With this data and guidance from the X.Org developers, I think we have a possible fix for the next Beta.
Can you ping this issue when the beta comes out with this please? I'd like to test it out.
Great! I'm glad I could contribute.
While it's only an annoyance if someone wants a workaround for now: killing the process instead of closing the application does not come with any lag/freezing (for me at least).
I don't know whether that would have other unforeseen consequences @bladegery - I used to have a problem whereby TF2 would take a long time to start (potentially 15 mins), which I suspect was the result of either it or Steam dying horribly on multiple occasions, accumulating some sort of cruft. The only solution was to move my .steam directory away, create a new and bare .steam, and then move the installed games back in (because I didn't feel like redownloading X gigs of stuff).
Still, that's an interesting observation.
I have the same issue, my system froze and I checked top processes on another tty and saw Xorg using 100% for minutes untill the system returned to normal.
Here is my Xorg -version:
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.17.0-1-MANJARO x86_64
Current Operating System: Linux manjaro 4.14.44-1-MANJARO #1 SMP PREEMPT Fri May 25 18:35:59 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.14-x86_64 root=UUID=64eecad0-4dd4-4949-a611-2aadfb6c98d1 rw quiet splash radeon.dpm=0 resume=UUID=02fe4fdf-860a-4c5d-bed9-fb489837d976
Build Date: 20 May 2018 06:17:37PM
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
@bladegery Killing the process only works sometimes for me.
Can you re-test with the recently released Beta client?
Moving to the beta now.
Looks like it's good now, didn't lag.
Though there is still this issue of a memory leak...
Seems like the beta solved my shutdown problems :)
Can you re-test with the recently released Beta client?
Was hoping to test this, but I can't find a way to opt out of the new chat beta without opting out of the client beta :/
Cool! With the beta, I just had TF2 running for about ten or eleven hours, and had no lag whatsoever on shutdown. Looking good!
Confirmed, issue has been fixed for me too for the new beta.
Thanks!
Seems this issue has reappeared in the current steam beta. Seeing it on Ubuntu 18.04.2 Steam build from April 16 2019
Hello @A-UNDERSCORE-D, please open a new issue report.
Yeah I could not decide if it was a decent idea or not. Will do
SDL_Qx1 2018-01
inxi -F here: https://imgur.com/iH3XH3H
This started happening about 3 weeks ago, I only recently got up to record the issue. After playing Dota for the whole day, stopping and shutting down steam causes it to gobble all of the UI responsiveness. What you can't see on that video is that hardware mouse still works and I can easily move it around. The UI just doesn't respond immediately. I don't know if it's because I have Discord on the whole time and have streamlined microphone on in Dota.
Yesterday I did
straceone of the steam processes and it gave mewait4(-1,before I had to forcefully shut down the system as I couldn't get control back. Do note that steam climbs to 1,7GiB before agreeing to shut itself. (shown in video)I am willing to provide any extra information you need to tackle this problem. Probably going to have to wait a day again so I can get steam clogged enough again.