<div dir="ltr"><div>I think the answer to my question is "no" because all the places in ResourceManager that access the ResourceWatcher were already protected by the mutex. So it wasn't that.<br><br>The crash occurs in qt code that looks like:<br>
<br>if(pending){<br></div>  dbus_unref(pending)<br>}<br><div>and asserts complaining that pending == NULL, so something odd is definitely happening.<br><br>I just ran kactivities under helgrind, but all I got so far was lots of warnings from deep inside Qt, which I think must be false positives...of course, I don't seem to hit the crash either, so maybe that's why. <br>
<br>The crash is connected to the ResourceWatcher used inside ResourceManagerPrivate, and I have to say that code makes no sense to me... <br><br>It creates a new object, then calls QObject->moveToThread()  on it. Then some (but not all) of the methods calls on that object are sent using QMetaObject. And I think the variable is better protected by just requiring caller take the lock, which it already does most of the time.<br>
<br>Actually, maybe that's the problem...<br><br></div><div>Incidentally, shouldn't the m_dataMutex also be held for Nepomuk2::ResourceData::watchEnabled()?<br><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 8 March 2013 11:52, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Friday 08 March 2013 11:10:50 Simeon Bird wrote:<br>
> > Note that I detected an error in the use of the "modification mutex" within<br>
> > Resource. I had used it only for "writes" to variables, but obviously the<br>
> ><br>
> >> reads must be mutex-protected too. Now that I understand the C++11 memory<br>
> >> model, it's a lot clearer :)<br>
> >> I'll rename the mutex then, it's not a "modification mutex", it's a mutex<br>
> >> for<br>
> >> the resource member variables.<br>
> ><br>
> > Uhm. Okay.<br>
><br>
> Does the extra locking fix<br>
> <a href="https://bugs.kde.org/show_bug.cgi?id=305024" target="_blank">https://bugs.kde.org/show_bug.cgi?id=305024</a> which is some sort of<br>
> memory corruption in the client-side resource<br>
> watcher? It seems to be threading related, since it is intermittent...<br>
<br>
</div></div>I can't say for sure. My fixes are not related to DBus at all.<br>
<br>
Is ResourceWatcher used from multiple threads at the same time? It's not<br>
mutex-protected at all. But it doesn't sound like a class that needs thread-<br>
safety to me.<br>
<br>
I suppose the only way to find out if there are still data races will be to run<br>
kmail in helgrind again, as I did some time ago...<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE, in particular KDE Frameworks 5<br>
<br>
</div></div></blockquote></div><br></div>