On 2/3/18 3:23 AM, Stig Bjørlykke wrote:
> On Fri, Feb 2, 2018 at 7:33 PM, Gerald Combs 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 c
On Fri, Feb 2, 2018 at 7:33 PM, Gerald Combs 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:/
Would it make sense to either expand README.developer or add a
README.threading, detailing the new startup procedure? Otherwise we might
run into issues later where users might face those exact issues.
On Fri, Feb 2, 2018 at 7:33 PM, Gerald Combs wrote:
> That's correct -- the main and RecentFil
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.
On 2/2/18 8:08 AM, Jaa
Hi,
Good question.
Just spitballing here, in what thread are the constructors running?
RecentFileStatus::filename_ is being set during construction, but is run()
already called from the other thread?
Jaap
> On 2 Feb 2018, at 15:04, Stig Bjørlykke wrote:
>
> When running with ThreadSanitizer
When running with ThreadSanitizer I constantly get this race condition
report from a QString in RecentFileStatus. Anyone else seen this? I
can't figure out the issue...
==
WARNING: ThreadSanitizer: data race (pid=41949)
Read of size 8 at 0x7b0c000c0dd0 by thread T18:
* #0 QSt
