Steam web helper uses 100% CPU all the time

steamclosed reviewedWeb Component

ValveSoftware/steam-for-linux#3877 · opened 2015-06-10 by ScoreUnder · updated 2019-07-18 · 5 comments · github

SScoreUnder 2015-06-10 github

I killed a steam web helper which was at 100% CPU and had hogged 78 hours of CPU time, in the hopes of having it return to reasonable levels, but it immediately respawned and started using 100% CPU again.

The problematic thread is this one (thread 3 in this list):

(gdb) inf thr
  Id   Target Id         Frame 
  18   Thread 0xf1108b40 (LWP 17647) "sandbox_ipc_thr" (running)
  17   Thread 0xf0907b40 (LWP 17649) "NetworkChangeNo" (running)
  16   Thread 0xf0106b40 (LWP 17650) "inotify_reader" (running)
  15   Thread 0xef905b40 (LWP 17651) "WorkerPool/1765" (running)
  14   Thread 0xef8e4b40 (LWP 17652) "WorkerPool/1765" (running)
  13   Thread 0xeed6eb40 (LWP 17657) "AudioThread" (running)
  12   Thread 0xef8c2b40 (LWP 17658) "OptimizingCompi" (running)
  11   Thread 0xee56db40 (LWP 17659) "Chrome_DBThread" (running)
  10   Thread 0xedd6cb40 (LWP 17660) "Chrome_FileThre" (running)
  9    Thread 0xed56bb40 (LWP 17661) "Chrome_FileUser" (running)
  8    Thread 0xecd6ab40 (LWP 17662) "Chrome_ProcessL" (running)
  7    Thread 0xec569b40 (LWP 17663) "Chrome_CacheThr" (running)
  6    Thread 0xebd68b40 (LWP 17664) "Chrome_IOThread" (running)
  5    Thread 0xeb567b40 (LWP 17665) "IndexedDB" (running)
  4    Thread 0xead66b40 (LWP 17666) "BrowserBlocking" (running)
  3    Thread 0xea549b40 (LWP 17667) "steamwebhelper" 0xf312d96f in __pthread_mutex_unlock_usercnt () from /usr/lib32/libpthread.so.0
  2    Thread 0xea2b8b40 (LWP 17668) "Proxy resolver" (running)
* 1    Thread 0xf20d4880 (LWP 17619) "steamwebhelper" (running)
(gdb) thr 3
[Switching to thread 3 (Thread 0xea549b40 (LWP 17667))]
#0  0xf312d96f in __pthread_mutex_unlock_usercnt () from /usr/lib32/libpthread.so.0
(gdb) bt
#0  0xf312d96f in __pthread_mutex_unlock_usercnt () from /usr/lib32/libpthread.so.0
#1  0xf758852b in ?? ()
#2  0xf75de291 in CCEFThread::CIPCTaskPost::Run() ()
#3  0xf76ff60e in SteamThreadTools::CThread::ThreadExceptionWrapper(void*) ()
#4  0xf76fe243 in ?? ()
#5  0xf76ff05d in ?? ()
#6  0xf77005c1 in SteamThreadTools::CThread::ThreadProc(void*) ()
#7  0xf312a1c3 in start_thread () from /usr/lib32/libpthread.so.0
#8  0xf3054dde in clone () from /usr/lib32/libc.so.6

It is the only one which is consistently running in user mode (i.e. not waiting on a syscall) and pausing that thread alone reduces cpu usage to 0% (occasionally spiking at 0.5%).

Other backtraces I've seen from that same thread:

#0  0xf312c65e in pthread_mutex_lock () from /usr/lib32/libpthread.so.0
#1  0xf75884e3 in ?? ()
#2  0xf75de291 in CCEFThread::CIPCTaskPost::Run() ()
#3  0xf76ff60e in SteamThreadTools::CThread::ThreadExceptionWrapper(void*) ()
#4  0xf76fe243 in ?? ()
#5  0xf76ff05d in ?? ()
#6  0xf77005c1 in SteamThreadTools::CThread::ThreadProc(void*) ()
#7  0xf312a1c3 in start_thread () from /usr/lib32/libpthread.so.0
#8  0xf3054dde in clone () from /usr/lib32/libc.so.6

#0  0xf75872ab in ?? ()
#1  0xf75de281 in CCEFThread::CIPCTaskPost::Run() ()
#2  0xf76ff60e in SteamThreadTools::CThread::ThreadExceptionWrapper(void*) ()
#3  0xf76fe243 in ?? ()
#4  0xf76ff05d in ?? ()
#5  0xf77005c1 in SteamThreadTools::CThread::ThreadProc(void*) ()
#6  0xf312a1c3 in start_thread () from /usr/lib32/libpthread.so.0
#7  0xf3054dde in clone () from /usr/lib32/libc.so.6

It is stuck inside this function:

(gdb) disas
Dump of assembler code for function _ZN10CCEFThread12CIPCTaskPost3RunEv:
   0xf75de264 <+0>: push   ebp
   0xf75de265 <+1>: push   edi
   0xf75de266 <+2>: push   esi
   0xf75de267 <+3>: push   ebx
   0xf75de268 <+4>: sub    esp,0x2c
   0xf75de26b <+7>: call   0xf7586f0a <__i686.get_pc_thunk.bx>
   0xf75de270 <+12>:    add    ebx,0x1b35fc
   0xf75de276 <+18>:    mov    esi,DWORD PTR [esp+0x40]
   0xf75de27a <+22>:    jmp    0xf75de295 <_ZN10CCEFThread12CIPCTaskPost3RunEv+49>
=> 0xf75de27c <+24>:    call   0xf75872a0
   0xf75de281 <+29>:    mov    DWORD PTR [esp+0x4],0xffffffff
   0xf75de289 <+37>:    mov    DWORD PTR [esp],eax
   0xf75de28c <+40>:    call   0xf75884be
   0xf75de291 <+45>:    test   al,al
   0xf75de293 <+47>:    jne    0xf75de2a5 <_ZN10CCEFThread12CIPCTaskPost3RunEv+65>
   0xf75de295 <+49>:    cmp    BYTE PTR [esi+0x35],0x0
   0xf75de299 <+53>:    je     0xf75de27c <_ZN10CCEFThread12CIPCTaskPost3RunEv+24>
   0xf75de29b <+55>:    xor    eax,eax
   0xf75de29d <+57>:    add    esp,0x2c
   0xf75de2a0 <+60>:    pop    ebx
   0xf75de2a1 <+61>:    pop    esi
   0xf75de2a2 <+62>:    pop    edi
   0xf75de2a3 <+63>:    pop    ebp
   0xf75de2a4 <+64>:    ret    
   0xf75de2a5 <+65>:    mov    ebp,DWORD PTR [esi+0x38]
   0xf75de2a8 <+68>:    mov    DWORD PTR [esp],0x18
   0xf75de2af <+75>:    call   0xf75849c0 <_Znwj@plt>
   0xf75de2b4 <+80>:    mov    edi,eax
   0xf75de2b6 <+82>:    lea    eax,[ebx-0x5050]
   0xf75de2bc <+88>:    mov    DWORD PTR [edi],eax
   0xf75de2be <+90>:    mov    DWORD PTR [edi+0x4],ebp
   0xf75de2c1 <+93>:    lea    eax,[ebx-0x1a064c]
   0xf75de2c7 <+99>:    mov    DWORD PTR [edi+0x8],eax
   0xf75de2ca <+102>:   mov    DWORD PTR [edi+0xc],0x0
   0xf75de2d1 <+109>:   mov    DWORD PTR [edi+0x14],0x0
   0xf75de2d8 <+116>:   mov    eax,DWORD PTR [ebp+0x0]
   0xf75de2db <+119>:   mov    DWORD PTR [esp],ebp
   0xf75de2de <+122>:   call   DWORD PTR [eax]
   0xf75de2e0 <+124>:   mov    DWORD PTR [esp+0x10],edi
   0xf75de2e4 <+128>:   mov    eax,DWORD PTR [edi]
   0xf75de2e6 <+130>:   add    edi,DWORD PTR [eax-0x1c]
   0xf75de2e9 <+133>:   mov    eax,DWORD PTR [edi]
   0xf75de2eb <+135>:   mov    DWORD PTR [esp],edi
   0xf75de2ee <+138>:   call   DWORD PTR [eax]
   0xf75de2f0 <+140>:   lea    edi,[esp+0x10]
   0xf75de2f4 <+144>:   mov    DWORD PTR [esp+0x4],edi
   0xf75de2f8 <+148>:   mov    DWORD PTR [esp],0x0
   0xf75de2ff <+155>:   call   0xf75fb580
   0xf75de304 <+160>:   mov    eax,DWORD PTR [esp+0x10]
   0xf75de308 <+164>:   test   eax,eax
   0xf75de30a <+166>:   je     0xf75de319 <_ZN10CCEFThread12CIPCTaskPost3RunEv+181>
   0xf75de30c <+168>:   mov    edx,DWORD PTR [eax]
   0xf75de30e <+170>:   add    eax,DWORD PTR [edx-0x1c]
   0xf75de311 <+173>:   mov    edx,DWORD PTR [eax]
   0xf75de313 <+175>:   mov    DWORD PTR [esp],eax
   0xf75de316 <+178>:   call   DWORD PTR [edx+0x4]
   0xf75de319 <+181>:   mov    DWORD PTR [esp+0x4],0xffffffff
   0xf75de321 <+189>:   mov    eax,DWORD PTR [esi+0x3c]
   0xf75de324 <+192>:   mov    DWORD PTR [esp],eax
   0xf75de327 <+195>:   call   0xf7700260
   0xf75de32c <+200>:   jmp    0xf75de295 <_ZN10CCEFThread12CIPCTaskPost3RunEv+49>
   0xf75de331 <+205>:   mov    esi,eax
   0xf75de333 <+207>:   lea    eax,[ebx-0x5124]
   0xf75de339 <+213>:   mov    DWORD PTR [edi],eax
   0xf75de33b <+215>:   mov    DWORD PTR [esp],edi
   0xf75de33e <+218>:   call   0xf7584fd0 <_ZdlPv@plt>
   0xf75de343 <+223>:   mov    DWORD PTR [esp],esi
   0xf75de346 <+226>:   call   0xf77103ef
   0xf75de34b <+231>:   mov    esi,eax
   0xf75de34d <+233>:   mov    DWORD PTR [esp],edi
   0xf75de350 <+236>:   call   0xf75de046 <_ZN9CefRefPtrI7CefTaskED2Ev>
   0xf75de355 <+241>:   mov    DWORD PTR [esp],esi
   0xf75de358 <+244>:   call   0xf77103ef
End of assembler dump.

Seems like it always hits that "je" at _ZN10CCEFThread12CIPCTaskPost3RunEv+53, leaving itself in a busy infinite loop.

Setting these 2 breakpoints, they never fire:

(gdb) b *0xf75de2a5
Breakpoint 1 at 0xf75de2a5
(gdb) b *0xf75de29b
Breakpoint 2 at 0xf75de29b

I hope that's enough info.

Kkisak-valve maintainer 2018-10-19 github

Hello @ScoreUnder, are you still experiencing this issue on an up to date system?

SScoreUnder 2018-10-22 github

I don't quite know when it resolved, but I don't think I've seen it happen in recent versions.

Kkisak-valve maintainer 2018-10-22 github

Thanks for the feedback, closing.

Sstevenroose 2018-11-28 github

I'm still experiencing this issue.. Wanted to try out Artifact today :D

Kkisak-valve maintainer 2018-11-28 github

Hello @stevenroose, please open a new issue report.

Nothing extracted yet.