CopyQ icon indicating copy to clipboard operation
CopyQ copied to clipboard

CopyQ hogs a core on Sway

Open cab404 opened this issue 2 years ago • 10 comments

First of all — you really are amazing. CopyQ is an irreplaceable tool which for me created whole workflows based around it. It’s so well thought out and made, that I am surprised I am not paying for it. Thank you for making this wonderful project!

Describe the bug After a while, copyq suddenly starts hogging a core.

To Reproduce Steps to reproduce the behavior:

  1. Use Sway 1.6/1.7
XDG_SESSION_TYPE=wayland
DESKTOP_SESSION=sway
QT_QPA_PLATFORMTHEME=gtk2
QT_STYLE_OVERRIDE=gtk2
QT_WAYLAND_DISABLE_WINDOWDECORATION=1

and basically, this 3. Wait for a while 4. Copyq starts hogging on it's main process. This does not show in process manager inside copyq

Expected behavior Not?

recvmsg(5, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(6, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=12, events=POLLIN}, {fd=20, events=POLLIN}, {fd=25, events=POLLIN}, {fd=27, events=POLLIN}], 9, 0) = 0 (Timeout)
recvmsg(5, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(6, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=12, events=POLLIN}, {fd=20, events=POLLIN}, {fd=25, events=POLLIN}, {fd=27, events=POLLIN}], 9, 0) = 0 (Timeout)

ad infinitum

Version, OS and Environment NixOS, https://github.com/cab404/nixos-config

CopyQ Clipboard Manager 6.0.1
Qt: 5.15.3
KNotifications: 5.89.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: NixOS 22.05 (Quokka)

I would’ve gladly reported, that I've built copyq with symbols, but that would be a lie

Using host libthread_db library "/nix/store/jcb7fny2k03pfbdqk1hcnh12bxgax6vf-glibc-2.33-108/lib/libthread_db.so.1".
0x00007fa03ed88c89 in poll () from /nix/store/jcb7fny2k03pfbdqk1hcnh12bxgax6vf-glibc-2.33-108/lib/libc.so.6
(gdb) bt
#0  0x00007fa03ed88c89 in poll () from /nix/store/jcb7fny2k03pfbdqk1hcnh12bxgax6vf-glibc-2.33-108/lib/libc.so.6
#1  0x00007fa03e6b8d4e in g_main_context_iterate.constprop () from /nix/store/dz9ai5i2xs58kjp093bw2jq60d2rl63r-glib-2.70.2/lib/libglib-2.0.so.0
#2  0x00007fa03e6b8e6f in g_main_context_iteration () from /nix/store/dz9ai5i2xs58kjp093bw2jq60d2rl63r-glib-2.70.2/lib/libglib-2.0.so.0
#3  0x00007fa03f4bf470 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /nix/store/57c3liyzynazqml1kcqviivgd97dxi2f-qtbase-5.15.3/lib/libQt5Core.so.5
#4  0x00007fa03f465e2b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /nix/store/57c3liyzynazqml1kcqviivgd97dxi2f-qtbase-5.15.3/lib/libQt5Core.so.5
#5  0x00007fa03f46e420 in QCoreApplication::exec() () from /nix/store/57c3liyzynazqml1kcqviivgd97dxi2f-qtbase-5.15.3/lib/libQt5Core.so.5
#6  0x00000000004cce4f in main ()

UI and everything does work, though.

cab404 avatar Feb 21 '22 00:02 cab404

Thanks for detailed bug report.

Can you share app logs (copyq logs or F12 from the main window)?

For the backtrace in gdb: poll() is just waiting for an event - it is not the culprit. The problem is probably in another thread if not even another copyq process. Can you share bt full output?

hluk avatar Feb 21 '22 06:02 hluk

I can confirm this bug.

I will also try to build copyq with symbols, hope but I have already killed the process :(.

The log is not very illuminating:

Warning [2022-02-21 10:32:47.870] <monitorClipboard-18500>: [default] QtWarning: DataControlOffer: timeout reading from pipe
Warning [2022-02-21 10:32:47.876] <monitorClipboard-18500>: ELAPSED 1016 ms acessing "text/plain"
Warning [2022-02-21 10:32:47.879] <monitorClipboard-18500>: ELAPSED 1020 ms acessing "UTF8:text/plain"
Warning [2022-02-21 10:54:55.748] <monitorClipboard-18500>: ELAPSED 673 ms acessing "text/plain"
Warning [2022-02-21 10:54:56.035] <monitorClipboard-18500>: ELAPSED 966 ms acessing "UTF8:text/plain"
Warning [2022-02-21 10:55:54.918] <monitorClipboard-18500>: ELAPSED 770 ms acessing "text/plain"
Warning [2022-02-21 10:56:23.493] <monitorClipboard-18500>: ELAPSED 23717 ms acessing "UTF8:text/plain"
Warning [2022-02-21 10:57:53.828] <monitorClipboard-18500>: Clipboard data expired, refusing to access old data
Warning [2022-02-21 15:17:42.899] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-21 15:19:12.145] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-21 15:25:44.844] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-21 17:43:32.326] <Server-24614>: CopyQ server is already running.
Warning [2022-02-21 17:43:41.592] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-22 09:23:52.396] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-22 09:23:52.657] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-22 09:23:53.375] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-22 09:23:55.305] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-22 09:23:55.490] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-22 09:23:55.893] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()
Warning [2022-02-22 09:23:56.671] <Server-17592>: [qt.qpa.wayland] QtWarning: Wayland does not support QWindow::requestActivate()

ghost avatar Feb 22 '22 01:02 ghost

So, i've repro-d it again, however I am not sure if this bt is at the right place. For some reason after Ctrl-C, threads apply all bt -full and continue it decided to quit right away. Maybe I needed to continue all threads..? copyq.txt

cab404 avatar Feb 22 '22 18:02 cab404

That looks like it could be a problem related to QtWaylandClient - though it still could be caused by the Wayland clipboard handler in CopyQ.

Can you share the debug logs? You need to start the app with COPYQ_LOG_LEVEL=DEBUG env variable set:

env COPYQ_LOG_LEVEL=DEBUG copyq

hluk avatar Feb 23 '22 14:02 hluk

okay, I finally got it with logs on — nothing interesting in there copyq-debug.log

I have it eating away my core rn, do you want me to dissect the process in some way?

cab404 avatar Apr 17 '22 20:04 cab404

@hluk please) it's kinda hard to live without copyq, and I have to keep it's process stopped, so it doesn't eat away all my battery)

cab404 avatar Apr 18 '22 19:04 cab404

Can you share the logs from copyq logs or from the "Show Log" dialog (F12 shortcut from main window? It's a bit hard to know what's going on without the timestamps.

Try to update to 6.1.0 if you have not done it yet.

Can you also check which processes (with full command line) are hogging the CPU? Perhaps with something like this:

top -b -n1 -c -p "$(pgrep -d, -f copyq)"

hluk avatar Apr 19 '22 06:04 hluk

image copyq.log

cab404 avatar Apr 19 '22 09:04 cab404

Does this happen if you use XWayland X11 compatibility layer on sway (using export XDG_SESSION_TYPE=xcb instead of XDG_SESSION_TYPE=wayland)?

The problem could be connected somehow to the application GUI style; try changing it:

# list available styles
copyq styles
# change style
copyq config style XXX
# restart the app

hluk avatar Apr 20 '22 07:04 hluk

Unset the QT_* overrides, set session type to xcb — gonna try living with that for a while)

cab404 avatar Apr 21 '22 09:04 cab404

I think it didn't come back on sway after using xcb.

cab404 avatar Nov 22 '23 07:11 cab404