Crash after requesting context menu (after reopening the project)
apaku at gmx.de
Thu Jul 31 06:39:29 UTC 2008
On 31.07.08 01:59:24, Manuel Breugelmans wrote:
> On Wednesday 30 July 2008 00:43:17 Andreas Pakulat wrote:
> > Hmmm... I can't see how this could happen. Granted the project pointer
> > itself isn't deleted until the event loop runs again after closing it,
> > but the project items are being deleted properly. So the project tree
> > has to have the new items and their project() pointer needs to be
> > "proper".
> > You should be able to debug this by simply printing out the pointer of
> > the project in projectcontroller::closeProject() before its deleted and
> > then also in veritas coverageplugin before the crash line. Those two
> > pointers should be different. If they are, there must be a problem
> > elsehwere.
> I've given this a long hard look and spotted the culprit. Not dvcs nor veritas
> but some obscure plugin loading code in projectcontroller [ the person that
> introduced this now owes +1 beer to Evgeniy & me :) ]
> I deduced this with the following minimal test cases:
> */ start kdev4 >> load project >> reopen project [no close, just recent-
> >project] >> context menu >> crash
> */ start kdev4 >> load project >> close project >> load project >> context
> menu >> no crash
> */ start kdev4 >> load cmake project >> load other cmake project >> reload
> cmake project >> context on reloaded >> no crash
> */ start kdev4 >> load cmake project >> load make project >> reload cmake
> project >> context menu reloaded >> crash
> On a reopen project ProjectController unloads the KDevCmakeBuilder plugin (IF
> no other open projects use it) then immediatly loads it again, which results
> in that segfault.
Did you find out why?
> Attached is a patch which:
> 1. Fixes this bug, by not unloading plugins when reloading a project which is
> redundant anyway
I don't like that. It duplicates code, reopen should be the same as
close+open so there's no reason to change that - IMHO.
> 2. Refactor the ProjectController->closeProject() member as this had started
> to rot
No it didn't. How do you know it rots? I'm not seeing much sense behind
factoring out code from closeProject, unless its used in more than one
place - which isn't the case (taking into account the above comment).
Besides: "getRidOfProject" is not a proper method name.
> 3. Remove faulty signals from ProjectController, which are also present in
> 4. Add a unit test for ProjectController
These two are ok.
> Index: shell/projectcontroller.h
> --- shell/projectcontroller.h (revision 839851)
> +++ shell/projectcontroller.h (working copy)
> @@ -55,18 +55,13 @@
> // IProject* currentProject() const;
> public Q_SLOTS:
> - bool openProject( const KUrl &KDev4ProjectFile = KUrl() );
> - bool projectImportingFinished( IProject* );
> - bool closeProject( IProject* );
> - void closeAllProjects();
> - bool configureProject( IProject* );
> + virtual bool openProject( const KUrl &KDev4ProjectFile = KUrl() );
> + virtual bool projectImportingFinished( IProject* );
> + virtual bool closeProject( IProject* );
> + virtual void closeAllProjects();
> + virtual bool configureProject( IProject* );
There's not really a need to add the virtual there, but I don't care
You will be singled out for promotion in your work.
More information about the KDevelop-devel