> On Nov. 16, 2014, 5:28 p.m., Thomas Lübking wrote: > > Do you have a backtrace of the condition? > > If there's trouble w/ ONE client onnly, i'd rather bet on a client bug (and > > KGlobal doesn't mention thread-safetyness) > > > > What you probably can do (as it's reproducible "somehow") is to add a > > QMutex. > > ::tryLock() before and ::unlock() after altering the value. > > If ::tryLock() ever returns "false" you can abort(); (or just yell a > > warning ;-) and got your confirmation
I've been trying to get backtraces of the condition for a very long time. Eventually I had the idea to break in QCoreApplication::exit, and when that fired I saw I got there through the ~KJob of a job I had already been suspecting. Next step was breaking conditionally on KGlobal::deref when s_refCount <= 1, and I had the luck of getting a hit almost immediately (on Linux, what's more). I have indeed been amazed that this happens only with KDevelop, but there is the `allowQuit` function that could be used by other applications. I see that KDE PIM sets it to true (`KGlobal::setAllowQuit(true)`; default is false, which prevents the whole issue) only in the various agents but not in the KMail, Kontact etc. I cannot find that call in KDevelop's code base so it's probably a library they use that sets toggles the setting. Setting a QMutex and checking if concurrent access ever occurs might work but still won't tell us if it's indeed the cause of the quitting issue. And it could be it never trips because the extra code could add enough overhead that I never stumble upon a locked mutex when calling ref or deref ... Again: a feature of a framework that is frequently used in multithreaded applications can be expected to be thread safe. That's why my original description states that I consider the fact that it isn't an important bug regardless of whether it's the cause of my issue. I regret haven given the background information now ... - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121134/#review70444 ----------------------------------------------------------- On Nov. 16, 2014, 4:53 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121134/ > ----------------------------------------------------------- > > (Updated Nov. 16, 2014, 4:53 p.m.) > > > Review request for KDE Software on Mac OS X and kdelibs. > > > Repository: kdelibs > > > Description > ------- > > I have been experiencing unexpected exits from KDevelop that were not due to > any kind of error in the KDevelop code; it was as if someone told the > application to exit normally. This happens mostly on OS X, but also sometimes > on Linux. > I finally traced this to `KGlobal::deref` reaching a zero reference count and > invoking `QCoreApplication::quit` when called from one of KDevelop's KJob > dtors. There does not appear to be a reference counting mismatch in the code, > so the issue might be due to a race condition in KGlobal::ref/deref. > > This patch introduces thread-safety to KGlobal's reference counting by > turning the simple global `static int s_refCount` into a `static QAtomicInt > s_refCount`. I consider this an important bug fix regardless of whether it > corrects the issue I have with KDevelop. > > > Diffs > ----- > > kdecore/kernel/kglobal.cpp cf003a4 > > Diff: https://git.reviewboard.kde.org/r/121134/diff/ > > > Testing > ------- > > On OS X 10.6.8 only for now. > > > Thanks, > > René J.V. Bertin > >
