clicking on media player when spotify is playing spawns http.so processes most likely to load album art. This is using CPU for no reason. STEPS TO REPRODUCE 1. play music in spotify app 2. click on Media Player OBSERVED RESULT cpu usage and hanging process EXPECTED RESULT load the album art and quit SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Please add the missing version information for Plasma.
(In reply to Christoph Feck from comment #1) > Please add the missing version information for Plasma. KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.61.0 Qt Version: 5.12.4
Thanks for the update; changing status.
Can confirm.
Probably trying to download album covers
Just did some some quick investigation, it's indeed from loading the album art. Plasmashell output (trimmed): ``` [12:10:03.102] kio_http(21273)/kf5.kio.kio_http: unknown: QUrl("http://o.scdn.co/image/ab67616d00001e0295bbdbc2ef2d339f081fbd13") ... [12:10:03.147] kio_http(21273)/kf5.kio.kio_http: unknown: ============ Sending Header: [12:10:03.148] kio_http(21273)/kf5.kio.kio_http: unknown: "GET /image/ab67616d00001e0295bbdbc2ef2d339f081fbd13 HTTP/1.1" [12:10:03.148] kio_http(21273)/kf5.kio.kio_http: unknown: "Host: o.scdn.co" [12:10:03.148] kio_http(21273)/kf5.kio.kio_http: unknown: "Connection: keep-alive" ... [12:10:04.721] kio_http(21273)/kf5.kio.kio_http: unknown: keepAlive = true [12:10:04.721] kio_http(21273)/kf5.kio.kio_http: unknown: [12:10:04.722] kio_http(21273)/kf5.kio.kio_http: unknown: keep alive ( 60 ) ... ``` => So the reason for the http.so process staying around is the keep-alive connection I think that makes sense it general, but the http.so shouldn't be using that much CPU when it in fact does nothing... Attached the debugger to the http.so process and found this: ``` (gdb) bt #0 0x00007f081befad26 in __GI_ppoll (fds=0x7fffae5af410, nfds=1, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39 #1 0x00007f081c6e5906 in qt_ppoll (fds=0x7fffae5af410, nfds=1, timeout_ts=0x7fffae5af340) at /home/kfunk/devel/src/qt5.12/qtbase/src/corelib/kernel/qcore_unix.cpp:132 #2 0x00007f081c6e59a1 in qt_safe_poll (fds=0x7fffae5af410, nfds=1, timeout_ts=0x7fffae5af3a0) at /home/kfunk/devel/src/qt5.12/qtbase/src/corelib/kernel/qcore_unix.cpp:162 #3 0x00007f081888c825 in qt_poll_msecs (fds=0x7fffae5af410, nfds=1, timeout=1) at ../../include/QtCore/5.12.6/QtCore/private/../../../../../../../../src/qt5.12/qtbase/src/corelib/kernel/qcore_unix_p.h:381 #4 0x00007f081888f33d in QNativeSocketEnginePrivate::nativeSelect (this=0x8bd700, timeout=1, checkRead=true, checkWrite=false, selectForRead=0x7fffae5af4de, selectForWrite=0x7fffae5af4df) at /home/kfunk/devel/src/qt5.12/qtbase/src/network/socket/qnativesocketengine_unix.cpp:1432 #5 0x00007f081888bd1f in QNativeSocketEngine::waitForReadOrWrite (this=0x9220f0, readyToRead=0x7fffae5af4de, readyToWrite=0x7fffae5af4df, checkRead=true, checkWrite=false, msecs=1, timedOut=0x0) at /home/kfunk/devel/src/qt5.12/qtbase/src/network/socket/qnativesocketengine.cpp:1120 #6 0x00007f081887474c in QAbstractSocket::waitForReadyRead (this=0x9070b0, msecs=1) at /home/kfunk/devel/src/qt5.12/qtbase/src/network/socket/qabstractsocket.cpp:2257 #7 0x00007f0818aafbc8 in KIO::ConnectionBackend::waitForIncomingTask (this=0x8fd580, ms=1) at /home/kfunk/devel/src/kf5/kio/src/core/connectionbackend.cpp:205 #8 0x00007f0818ae9ae2 in KIO::SlaveBase::dispatchLoop (this=0x7fffae5af5f0) at /home/kfunk/devel/src/kf5/kio/src/core/slavebase.cpp:328 #9 0x00007f0816a7f0cb in kdemain (argc=<optimized out>, argv=<optimized out>) at /home/kfunk/devel/src/kf5/kio/src/ioslaves/http/http.cpp:115 #10 0x000000000020a49f in launch (argc=4, _name=0x84dad8 "/home/kfunk/devel/install/kf5/lib/x86_64-linux-gnu/plugins/kf5/kio/http.so", args=<optimized out>, cwd=0x0, envc=0, envs=<optimized out>, reset_env=<optimized out>, tty=0x0, avoid_loops=<optimized out>, startup_id_str=0x2041a6 "0") at /home/kfunk/devel/src/k f5/kinit/src/kdeinit/kinit.cpp:704 #11 0x000000000020abe5 in handle_launcher_request (sock=7, who=0x84dad0 "\004") at /home/kfunk/devel/src/kf5/kinit/src/kdeinit/kinit.cpp:1142 #12 0x0000000000208ccb in handle_requests (waitForPid=<optimized out>) at /home/kfunk/devel/src/kf5/kinit/src/kdeinit/kinit.cpp:1335 #13 0x00000000002084e1 in main (argc=1, argv=0x7fffae5aff48) at /home/kfunk/devel/src/kf5/kinit/src/kdeinit/kinit.cpp:1773 ``` We're apparently excessively calling QAbstractSocket::waitForReadyRead(msecs=1) in a loop which causes high CPU usage. Adding a few breakpoints and continuing running the process seems to confirm this: ``` Thread 1 "http.so" hit Breakpoint 2, 0x00007f081887474c in QAbstractSocket::waitForReadyRead (this=0x9070b0, msecs=1) at /home/kfunk/devel/src/qt5.12/qtbase/src/network/socket/qabstractsocket.cpp:2257 (gdb) c Continuing. Thread 1 "http.so" hit Breakpoint 1, 0x00007f0818ae9ae2 in KIO::SlaveBase::dispatchLoop (this=0x7fffae5af5f0) at /home/kfunk/devel/src/kf5/kio/src/core/slavebase.cpp:328 (gdb) c Continuing. (and repeating) ``` So the problem seems to be deeply in KIO Core. Can someone more familiar with the framework shed some light on this and ensure that the implementation of KIO::SlaveBase::dispatchLoop() is sane?
See also Bug 392768 and Bug 400155
*** This bug has been marked as a duplicate of bug 392768 ***