Open CyberShadow opened 6 years ago
Looks like the shared memory object is not going away, even after the attach/detach.
Workaround: rm /tmp/qipc_*copyq*
.
And now I can't reproduce this any more.
In any case, some potential actionables:
createSystemMutex
does not log an error if !tryAttach(shmem) || !tryAttach(shmem)
succeeds (and thus the function returns nullptr
)./tmp
. At least one seems to be due to QSharedMemory
already using a QSystemSemaphore
under the hood, so the one used by createSystemMutex
may be redundant.Thanks for the investigation. I'll try to fix the shared memory issue.
I usually avoid recursion if it can lead to stack overflow (recursion is only good if there is fixed upper limit of calls). Unfortunately, it's bit overlooked, but directly connecting slots to Qt signals can lead to these problems. In this case, using queued connection instead of direct one would probably solve it.
BTW, I had some issues with QSharedMemory
in past on some systems so there are some workarounds in CopyQ. But perhaps the issues were resolved in Qt.
CopyQ is failing to start. Upon startup, it prints the following message about 11000 times, then segfaults:
With
COPYQ_LOG_LEVEL=TRACE
:(last four lines repeat about 11000 times, exact count varies).
Running copyq in gdb shows that the segmentation fault is due to a stack overflow:
CopyQ 3.1.2 running on Arch Linux x86_64.
No copyq processes seem to be running.
I tried removing
~/.config/copyq
with the same effect.