protonscr

steamcmd for linux32 hangs indefinitely on some DigitalOcean droplets (possibly due to CPU split lock traps?)

steamopen SteamCMD
ValveSoftware/steam-for-linux#13525 · opened 2026-08-19 by ScarlettHoefler · updated 2026-08-19 · 0 comments · github
SScarlettHoefler 2026-08-19 github

Your system information

  • Steam client version (build number or date): Steam Console Client (c) Valve Corporation - version 1785799152
  • Distribution (e.g. Ubuntu): Ubuntu
  • Opted into Steam client beta?: No
  • Have you checked for system updates?: Yes
  • Steam Logs: N/A
  • GPU: None

Please describe your issue in as much detail as possible:

When trying to run steamcmd on a DigitalOcean droplet, it would hang. It was able to successfully update when necessary, but would always get stuck afterwards, seemingly hanging indefinitely.

This issue was first discovered in a Docker container, but also applies when trying to run steamcmd on the host machine. I first discovered this issue at the start of May, and thought it was related to Docker changes due to issues lining up almost exactly with Docker adding mitigations for the CopyFail vulnerability (CVE-2026-31431), so at first I thought it was that, but now it seems incidental and unrelated.

I could run it with the command ./steamcmd.sh +login anonymous +quit and it would never progress past here:

Redirecting stderr to '/root/Steam/logs/stderr.txt'  
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".  
[  0%] Checking for available update...  
[----] Downloading update (0 of 40321 KB)...  
[  0%] Downloading update (0 of 40321 KB)...  
[  0%] Downloading update (0 of 40321 KB)...  
[  0%] Downloading update (3362 of 40321 KB)...  
[  8%] Downloading update (7496 of 40321 KB)...  
[ 18%] Downloading update (11258 of 40321 KB)...  
[ 27%] Downloading update (15018 of 40321 KB)...  
[ 37%] Downloading update (18317 of 40321 KB)...  
[ 45%] Downloading update (21203 of 40321 KB)...  
[ 52%] Downloading update (23749 of 40321 KB)...  
[ 58%] Downloading update (26271 of 40321 KB)...  
[ 65%] Downloading update (27988 of 40321 KB)...  
[ 69%] Downloading update (29542 of 40321 KB)...  
[ 73%] Downloading update (30820 of 40321 KB)...  
[ 76%] Downloading update (32092 of 40321 KB)...  
[ 79%] Downloading update (33465 of 40321 KB)...  
[ 82%] Downloading update (34719 of 40321 KB)...  
[ 86%] Downloading update (35997 of 40321 KB)...  
[ 89%] Downloading update (37379 of 40321 KB)...  
[ 92%] Downloading update (38637 of 40321 KB)...  
[ 95%] Downloading update (39944 of 40321 KB)...  
[ 99%] Downloading update (40321 of 40321 KB)...  
[100%] Download Complete.  
[----] Applying update...  
[----] Extracting package...  
[----] Extracting package...  
[----] Extracting package...  
[----] Extracting package...  
[----] Installing update...  
[----] Installing update...  
[----] Installing update...  
[----] Installing update...  
[----] Installing update...  
[----] Installing update...  
[----] Installing update...  
[----] Installing update...  
[----] Installing update...  
[----] Cleaning up...  
[----] Update complete, launching...  
steamcmd.sh[3101390]: Starting  /root/steamtest/linux32/steamcmd  
Redirecting stderr to '/root/Steam/logs/stderr.txt'  
Logging directory: '/root/Steam/logs'

Or, if an update was not necessary, it would just give:

steamcmd.sh[2307]: Starting  /root/steamtest/linux32/steamcmd
Redirecting stderr to '/root/Steam/logs/stderr.txt'
Logging directory: '/root/Steam/logs'

...and then it would sit indefinitely, until the job timed out.

Workaround: Running with STEAM_PLATFORM=linux64, however, does not run into this issue and works as expected.

It seems plausible that the issue is steamcmd getting caught in split lock traps on the CPU?

root@gitlab-runner-large-n0:~# pid=$(pgrep -f 'linux32/steamcmd' | head -1)  
dmesg -T | grep -iE 'split lock|x86/split' | tail -5  

[Tue Aug 18 23:24:47 2026] x86/split lock detection: #AC: steamcmd/3100370 took a split_lock trap at address: 0x568f4d9f  
[Tue Aug 18 23:24:47 2026] x86/split lock detection: #AC: steamcmd/3099276 took a split_lock trap at address: 0x568a9d9f  
[Tue Aug 18 23:24:47 2026] x86/split lock detection: #AC: steamcmd/3100996 took a split_lock trap at address: 0x56861d9f  
[Tue Aug 18 23:24:47 2026] x86/split lock detection: #AC: steamcmd/3100454 took a split_lock trap at address: 0x5688ed9f  
[Tue Aug 18 23:24:47 2026] x86/split lock detection: #AC: steamcmd/3099116 took a split_lock trap at address: 0x56817d9f

However, I was unable to disable split lock detection through GRUB settings to try and validate if that would fix it (which makes sense; it's a cloud VM)

The build machine this occurs on is a DigitalOcean droplet initiated with size slug c2-32vcpu-64gb-intel, using image docker-20-04.

Based on lscpu, the actual droplet is running an INTEL(R) XEON(R) GOLD 6548N. Some additional info about the OS:

root@gitlab-runner-large-n0:~/steamtest# uname -a
Linux gitlab-runner-large-n0 5.15.0-187-generic [#197](/issue/ValveSoftware/steam-for-linux/197)-Ubuntu SMP Fri Jul 17 19:17:01 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Here's an attempt at throwing gdb at it to see where it's hanging. Candidly, I'm not super familiar with gdb, so I did get this command recommended by Claude to try and help collect more data:

root@gitlab-runner-large-n0:~# pid=$(pgrep -f 'linux32/steamcmd' | head -1); echo "pid=$pid"  
  
# 1) Has the burn profile changed now that SLD is off?  
#    Before: stime >> utime (kernel trap handling). If it's now utime-dominant -> pure userspace spin.  
#    If stime STILL dominates with no split-lock dmesg -> something else kernel-side (e.g. a page-fault loop).  
dmesg -T | grep -i 'split lock' | tail -2   # expect nothing new since reboot  
awk '{print "utime="$14, "stime="$15, "minflt="$10, "majflt="$12}' /proc/$pid/stat; sleep 5  
awk '{print "utime="$14, "stime="$15, "minflt="$10, "majflt="$12}' /proc/$pid/stat  
  
# 2) THE key evidence: backtrace + the actual loop instructions.  
#    Run it twice ~10s apart: same EIP range both times = tight spin; wandering EIP = it's progressing.  
gdb -p $pid -batch -ex 'set pagination off' -ex 'bt 12' -ex 'info registers eip' -ex 'x/10i $pc-10' 2>&1 | tail -30  
  
# 3) Redo strace writing to a file (last attempt produced suspiciously literally nothing):  
timeout 20 strace -f -tt -p $pid -o /tmp/att.log; echo "lines: $(wc -l < /tmp/att.log)"; head -30 /tmp/att.log  
pid=1941  
[Tue Aug 18 23:42:51 2026] x86/split lock detection: #AC: steamcmd/2008 took a split_lock trap at address: 0x56822d9f  
[Tue Aug 18 23:42:51 2026] x86/split lock detection: #AC: steamcmd/1941 took a split_lock trap at address: 0x56867d9f  
utime=2195 stime=31235 minflt=360 majflt=117  
utime=2228 stime=31702 minflt=360 majflt=117  
warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.  
  
warning: Expected absolute pathname for libpthread in the inferior, but got target:/usr/lib/i386-linux-gnu/libc.so.6.  
  
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.  
0x56867d9f in ?? ()  
#0  0x56867d9f in ?? ()  
#1  0x56c8620f in ?? ()  
#2  0x56a89aed in ?? ()  
#3  0x56ae83a8 in ?? ()  
#4  0x56a858f0 in ?? ()  
#5  0xf7c5dcf9 in ?? () from target:/usr/lib/i386-linux-gnu/libc.so.6  
#6  0xf7c5dd89 in pthread_once () from target:/usr/lib/i386-linux-gnu/libc.so.6  
#7  0x56ae84be in ?? ()  
#8  0x56a85ded in ?? ()  
#9  0x56b36823 in ?? ()  
[#10](/issue/ValveSoftware/steam-for-linux/10) 0x56c862d3 in ?? ()  
[#11](/issue/ValveSoftware/steam-for-linux/11) 0x56c77d8a in ?? ()  
eip            0x56867d9f          0x56867d9f  
   0x56867d95:  pop    %esp  
   0x56867d96:  and    $0x4,%al  
   0x56867d98:  mov    (%esp),%ebx  
   0x56867d9b:  mov    0x4(%esp),%ecx  
=> 0x56867d9f:  lock cmpxchg8b 0x0(%ebp)  
   0x56867da4:  jne    0x56867d81  
   0x56867da6:  add    $0x14,%esp  
   0x56867da9:  mov    %esi,%eax  
   0x56867dab:  mov    %edi,%edx  
   0x56867dad:  pop    %ebx  
[Inferior 1 (process 1941) detached]  
strace: Process 1941 attached  
strace: Process 1941 detached  
lines: 0

Steps for reproducing this issue:

  1. Create a DigitalOcean droplet with size slug c2-32vcpu-64gb-intel and image docker-20-04
  2. Install steamcmd, or use a Docker container (e.g. docker run -it --name=steamcmd cm2network/steamcmd bash, or docker run --rm -t steamcmd/steamcmd:latest +login anonymous +quit)
  3. When attempting to run ./steamcmd.sh +login anonymous +quit, it hangs indefinitely

Nothing extracted yet.