Lukas Holecek

It is caused by a **data race** when handling the selected items. I've added some functionality to avoid situations like this some time ago but the Move to Trash command...

Fixed. Can you add [the fixed commands](https://github.com/hluk/copyq-commands/tree/master/Application#undoable-move-to-trash) again?

I fixed the command again. > You write about "fixed commands" - which are them? I said "fixed command**s**" because there are two commands grouped together under same source `.ini`...

:disappointed: Damn, the new "Move to Trash" command has problems with large data items - like larger images with multiple image formats.

I fixed those two commands again.

Can you check if it prints any errors/warnings with the following command? ```bash flatpak run --env=COPYQ_LOG_LEVEL=DEBUG --env=QT_LOGGING_RULES="*.debug=true;qt.*.debug=false" com.github.hluk.copyq ``` If it is a problem with tray/status icon integration (it uses...

Any chance you can get **stacktrace** when the app gets stuck? Couple of **other env variable overrides** you can try: ``` flatpak run --env=COPYQ_DEFAULT_ICON=1 com.github.hluk.copyq flatpak run --env=COPYQ_SESSION_COLOR=green com.github.hluk.copyq flatpak...

@acancell-redhat Thanks! Unfortunately, I cannot tell where it is stuck from the syscall logs. Can you also try the following? ``` flatpak run --env=QT_QPA_PLATFORM=xcb --env=COPYQ_LOG_LEVEL=DEBUG --env=QT_LOGGING_RULES="*.debug=true" com.github.hluk.copyq ```

No luck figuring out the problem. I would need to download RHEL 8.6 and debug it in VM.

CopyQ gets stuck waiting on some subprocess. Here is the backtrace: ``` #0 0x00007ffff2f9391d in syscall () from /lib64/libc.so.6 #1 0x00007ffff3e9bf1c in sys_waitid (ru=0x0, options=4, infop=0x7fffffffd670, pid_or_pidfd=22, which=3) at io/../../3rdparty/forkfd/forkfd_linux.c:185...