ERROR: Restarting clipboard monitor (Failed to start local server)

[CyberShadow]

CopyQ is failing to start. Upon startup, it prints the following message about 11000 times, then segfaults:

ERROR: Restarting clipboard monitor (Failed to start local server "/home/vladimir/.config/copyq/.copyq_m"!)

With COPYQ_LOG_LEVEL=TRACE:

TRACE: Opened session mutex: copyq_mutex
DEBUG: QtDebug: QUimPlatformInputContext() (:0, )
DEBUG: QtDebug: isValid() (:0, )
TRACE: Created session mutex: copyq_mutex
DEBUG: Server "/home/vladimir/.config/copyq/.copyq_s" started.
Note: Loading plugin: /usr/lib/copyq/plugins/libitemdata.so
Note: Loading plugin: /usr/lib/copyq/plugins/libitemencrypted.so
Note: Loading plugin: /usr/lib/copyq/plugins/libitemfakevim.so
Note: Loading plugin: /usr/lib/copyq/plugins/libitemimage.so
Note: Loading plugin: /usr/lib/copyq/plugins/libitemnotes.so
Note: Loading plugin: /usr/lib/copyq/plugins/libitempinned.so
Note: Loading plugin: /usr/lib/copyq/plugins/libitemsync.so
Note: Loading plugin: /usr/lib/copyq/plugins/libitemtags.so
Note: Loading plugin: /usr/lib/copyq/plugins/libitemtext.so
DEBUG: Loading configuration
DEBUG: Tab "&clipboard": Loading items
DEBUG: Tab "&clipboard": 0 items loaded
DEBUG: Configuration loaded
DEBUG: Starting monitor
ERROR: Restarting clipboard monitor (Failed to start local server "/home/vladimir/.config/copyq/.copyq_m"!)
DEBUG: Terminating monitor
DEBUG: Monitor terminated
DEBUG: Starting monitor
ERROR: Restarting clipboard monitor (Failed to start local server "/home/vladimir/.config/copyq/.copyq_m"!)
DEBUG: Terminating monitor
DEBUG: Monitor terminated

(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:

#0  0x00007fc10494a554 in ?? () from /usr/lib/libQt5Core.so.5
#1  0x00007fc10494a982 in ?? () from /usr/lib/libQt5Core.so.5
#2  0x00007fc10494b07f in QRegExp::indexIn(QString const&, int, QRegExp::CaretMode) const () from /usr/lib/libQt5Core.so.5
#3  0x00007fc104961d27 in QString::replace(QRegExp const&, QString const&) () from /usr/lib/libQt5Core.so.5
#4  0x0000555555623897 in getConfigurationFilePath(QString const&) ()
#5  0x0000555555623a47 in settingsDirectoryPath() ()
#6  0x0000555555613345 in serverName(QString const&) ()
#7  0x0000555555602f84 in ClipboardServer::startMonitoring() ()
#8  0x00005555556032dd in ClipboardServer::monitorConnectionError(QString const&) ()
#9  0x000055555573a621 in ?? ()
#10 0x00007fc104aef126 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5
#11 0x0000555555731fb5 in RemoteProcess::connectionError(QString const&) ()
#12 0x000055555560c5d2 in RemoteProcess::start(QString const&, QStringList const&) ()
#13 0x0000555555603058 in ClipboardServer::startMonitoring() ()
#14 0x00005555556032dd in ClipboardServer::monitorConnectionError(QString const&) ()
#15 0x000055555573a621 in ?? ()
#16 0x00007fc104aef126 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5
#17 0x0000555555731fb5 in RemoteProcess::connectionError(QString const&) ()
#18 0x000055555560c5d2 in RemoteProcess::start(QString const&, QStringList const&) ()
#19 0x0000555555603058 in ClipboardServer::startMonitoring() ()
#20 0x00005555556032dd in ClipboardServer::monitorConnectionError(QString const&) ()
#21 0x000055555573a621 in ?? ()

(... last 6 frames repeat ...)

#71305 0x0000555555603058 in ClipboardServer::startMonitoring() ()
#71306 0x0000555555605e1b in ClipboardServer::ClipboardServer(QApplication*, QString const&) ()
#71307 0x00005555555f1bb1 in ?? ()
#71308 0x00005555555f0d86 in main ()

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.

[CyberShadow]

Looks like the shared memory object is not going away, even after the attach/detach.

Workaround: rm /tmp/qipc_*copyq*.

[CyberShadow]

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).
• Retrying by recursion could probably be improved by adding a limit and/or a human-readable error message.
• There seems to be some redundancy, as a CopyQ instance creates 5 files in /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.

[hluk]

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.

[hluk]

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.