Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] ThreadSanitizer issue in RecentFileStatus()

From: Gerald Combs <gerald@xxxxxxxxxxxxx>
Date: Sat, 3 Feb 2018 10:32:29 -0800
On 2/3/18 3:23 AM, Stig Bjørlykke wrote:
> On Fri, Feb 2, 2018 at 7:33 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:
>> That's correct -- the main and RecentFileStatus threads could operate on the filename at the same time. I think the data race is harmless in this case, but it's easy enough to create a local copy of the filename. Fix inbound at https://code.wireshark.org/review/#/c/25572.
> 
> I'm still getting a similar race condition report from
> RecentFileStatus.  Even if it's harmless it would have been good to
> fix this to make it possible to run with TSAN and "Pause on issues".
> 
> ==================
> WARNING: ThreadSanitizer: data race (pid=4733)
>   Read of size 8 at 0x7e800059edb0 by main thread:
>   * #0 QString::QString(QString const&) qstring.h:906
> (Wireshark:x86_64+0x100039256)
>     #1 QString::QString(QString const&) qstring.h:907
> (Wireshark:x86_64+0x100038498)
>     #2 WiresharkApplication::qt_static_metacall(QObject*,
> QMetaObject::Call, int, void**) moc_wireshark_application.cpp:239
> (Wireshark:x86_64+0x1000bb990)
>     #3 QObject::event(QEvent*) <null> (QtCore:x86_64+0x211b80)
>     #4 QApplicationPrivate::notify_helper(QObject*, QEvent*) <null>
> (QtWidgets:x86_64+0x119ac)
>     #5 start <null> (libdyld.dylib:x86_64+0x1114)
> 
>   Previous write of size 8 at 0x7e800059edb0 by thread T14:
>   * #0 QString::QString(QString const&) qstring.h:906
> (Wireshark:x86_64+0x10003926d)
>     #1 QString::QString(QString const&) qstring.h:907
> (Wireshark:x86_64+0x100038498)
>     #2 RecentFileStatus::run() recent_file_status.cpp:32
> (Wireshark:x86_64+0x1005000cc)
>     #3 non-virtual thunk to RecentFileStatus::run()
> recent_file_status.cpp (Wireshark:x86_64+0x10050020c)
>     #4 <null> <null> (QtCore:x86_64+0x27b6d)

Does ThreadSanitizer support QMutex on macOS (which appears to use Mach semaphores)? Switching from Qt::BlockingQueuedConnection to Qt::QueuedConnection fixed the warning here, which suggests that it's ignoring Qt's event mutex. I get similar warnings for GMutex when using TSAN on Linux.

A switch from Qt::BlockingQueuedConnection to Qt::QueuedConnection is inbound in change 25576.