kdevelop exitting on its own - GOTCHA!

[Kevin Funk]

On Friday 14 November 2014 17:47:03 René J.V. Bertin wrote:
> On Thursday November 06 2014 03:52:25 Aleix Pol wrote:
> > What you should be looking for is what is making the event loop end. You
> > already see that the event loop ends because the application shuts down...
> > 
> > Aleix
> 
> Well, seems like the issue *IS* related to the parsing jobs after all. It's
> been a while, but today, while I was in the middle of an edit (!!!!)
> KDevelop decided to quit on me again. Fortunately I'd decided to attach a
> debugger:
> 
> Breakpoint 1, QCoreApplication::exit (returnCode=0) at
> kernel/qcoreapplication.cpp:1258 1258        if (!self)
> (gdb) bt
> #0  QCoreApplication::exit (returnCode=0) at
> kernel/qcoreapplication.cpp:1258 warning: .o file
> "/Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_
> kdelibs4/kdelibs4/work/build/kdecore/CMakeFiles/kdecore.dir/jobs/kjob.o"
> more recent than executable timestamp in
> "/Volumes/Debian/MP6/lib/libkdecore.5.14.2.dylib" warning: Couldn't open
> object file
> '/Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_
> kdelibs4/kdelibs4/work/build/kdecore/CMakeFiles/kdecore.dir/jobs/kjob.o' #1 
> 0x00000001000e4f24 in KJob::~KJob ()
> #2  0x0000000104b45ead in KDevelop::ParseProjectJob::~ParseProjectJob
> (this=0x1207c0160) at
> /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_k
> devplatform-git/kdevplatform-git/work/kdevplatform-git-1.7.0/language/backgr
> oundparser/parseprojectjob.cpp:39 #3  0x0000000104b45c4f in
> KDevelop::ParseProjectJob::qt_static_metacall (_o=0x104b45ead,
> _c=886046720, _id=29421120, _a=0x7fff70b5c650) at parseprojectjob.moc:52
> Previous frame inner to this frame (gdb could not unwind past this frame)
> 
> I don't understand why I don't have debugging info for ~KJob (it ought to be
> there ... unless I maybe was already exiting from ~KJob in which case we
> could suspect KGlobal::deref()?
> 
> And with that: GOTCHA!
> 
>     /**
>      * Tells KGlobal that one operation such as those described in ref()
> just finished. * This call makes the QApplication quit if the counter is
> back to 0. */
>     KDECORE_EXPORT void deref();
> 
> 
> and just below:
> 
>     /**
>      * If refcounting reaches 0 (or less), and @p allowQuit is true, the
> instance of the application * will automatically be exited. Otherwise, the
> application will not exit automatically. *
>      * This is used by KMainWindow to allow quitting after the first
> mainwindow is created, * and is used by special applications like
> kfmclient, to allow quitting even though * no mainwindow was created.
>      *
>      * However, don't try to call setAllowQuit(false) in applications, it
> doesn't make sense. * If you find that the application quits too early when
> closing a window, then consider * _what_ is making your application still
> alive to the user (like a systray icon or a D-Bus object) * and use
> KGlobal::ref() + KGlobal::deref() in that object.
>      *
>      * @since 4.1.1
>      */
>     KDECORE_EXPORT void setAllowQuit(bool allowQuit);
> 
> Does any of your classes inheriting KJob do an explicit KGlobal::deref (or
> one too many) when the task is finished?
> 
> Cheers,
> René

Ah, the joy of refcounting...

I've dedicated a whole blog post for debugging these kind of issues with GDB:
  http://kfunk.org/2014/08/29/scripting-gdb-to-execute-commands-at-particular-breakpoints/

First of all:
- I've never seen this issue on Linux, so it must be OSX specific
- We don't call KGlobal::deref explicitly afaics

So, if you want to debug this you probably should read my blog post and/or 
about scripting your favorite debugger. I don't see other opportunities 
really. *Any* loaded KDE library can cause this, since KGlobal is, well, 
global, and everything can modify it.

Follow-up question: Is that the only KDE app behaving like that?

Greets

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org