https://bugs.kde.org/show_bug.cgi?id=494924
postix <pos...@posteo.eu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|UPSTREAM |---
Status|RESOLVED |REOPENED
Ever confirmed|0 |1
Summary|Sudden crash during a |Racy crash during a session
|session in (anonymous |in (anonymous
|namespace)::sendChangedSign |namespace)::sendChangedSign
|al (updatedFiles=...) |al (updatedFiles=...)
--- Comment #2 from postix <pos...@posteo.eu> ---
Thiago Macieira from Qt has done an incredible job in analyzing the backtrace,
see the link in URL field above:
> The outermost frame that you pasted is not QtDBus code
> (filecontentindexer.cpp:27 and RIP = 0x000055b655c6bfdf,
> indicating code located in the main executable
> [unless you have Clear Linux's optimisations, which you don't]).
> This means this content is not running in the QDBusConnectionManager
> thread, so this is not a QtDBus race condition either.
> That frame is
> https://invent.kde.org/frameworks/baloo/-/blob/master/src/file/filecontentindexer.cpp#L21-28:
```
void sendChangedSignal(const QStringList& updatedFiles)
{
auto message = QDBusMessage::createSignal(QStringLiteral("/files"),
QStringLiteral("org.kde"),
QStringLiteral("changed"));
message.setArguments({updatedFiles});
QDBusConnection::sessionBus().send(message);
}
```
> As far as I can tell, the corruption happened above this too. This
> QStringList is pointing to garbage.
> https://retrace.fedoraproject.org/faf/reports/1035460/
> says this is running on a thread running Baloo::FileContentIndexer::run():
```
// Notify some metadata may have changed
sendChangedSignal(m_updatedFiles);
m_updatedFiles.clear();
```
> Aside from the run() function itself, m_updatedFiles is modified in
> FileContentIndexer::slotFinishedIndexingFile, which is connected
> at the beginning of the run() function:
```
ExtractorProcess process{m_extractorPath};
connect(&process, &ExtractorProcess::startedIndexingFile, this,
&FileContentIndexer::slotStartedIndexingFile);
connect(&process, &ExtractorProcess::finishedIndexingFile, this,
&FileContentIndexer::slotFinishedIndexingFile);
```
> FileContentIndexer is a public QObject, public QRunnable.
> It is used as a member in FileIndexScheduler (m_contentIndexer).
> There's no call to moveToThread in Baloo anywhere and QThreadPool will not do
> it for you.
> This means that Qt::AutoConnection connection above will resolve as a
> Qt::QueuedConnection
> and deliver the signal to the thread where FileIndexScheduler was created,
> not the one the FileContentIndexer runnable is running on.
> Since FileContentIndexer::slotFinishedIndexingFile does not lock any mutexes,
> this is the race condition
> This can be fixed by adding Qt::DirectConnection to the two connect
> statements above.
--
You are receiving this mail because:
You are watching all bug changes.
