[Bug 221109] Crash when deleting multiple folder [ProjectManagerViewPlugin::removeFolderFromContextMenu, ProjectManagerViewPlugin::qt_metacall, QMetaObject::metacall]

Andreas Pakulat apaku at gmx.de
Mon Jan 4 13:43:00 UTC 2010


On 04.01.10 00:35:52, Milian Wolff wrote:
> On Sunday 03 January 2010 21:12:46 Andreas Pakulat wrote:
> > I'm moving this to the devel list as thats a better place to discuss
> > technical details.
> > 
> > On 03.01.10 18:32:52, Milian Wolff wrote:
> > > But you are aware that the watcher is the culprit here and that this
> > > would fix the crash(es)?
> > 
> > So the problem is:
> > 
> > 1. User selects multiple cmake-known dirs and selects "delete"
> 
> 1b) the projectmanagerview deletes the first folder
> 
> > 2. User gets to the cmake edit dialog, because the first item is about
> > to be removed
> > 3. User deletes multiple entries from the cmake files
> > 4. CMake stores the new file, which triggers the watcher, which reloads
> > the file which deletes the items from the model
> > 5. the next item is tried to be removed, but it doesn't exist anymore
> 
> 5. is again the projectmanagerview, not the cmakemanager.

Ah, so the problem is that the manager API allows for removal of a single
item only? If that is the case, then we have two options (additionally to
moving the cmake-file-change after everything else):

- adjust the manager API to allow for multiple items being deleted in one
  go
- disable deletion if more than one item is selected in the tree

I'd favor the API change :)
 
> > So the first question is: Why is the watcher active for a file that is
> > being saved by us. Or rather, why do we reload it if we just saved it. I
> > had a similar problem at work and the solution was to simply store the
> > modification time right after the save and only reload if the
> > modification time is newer than this stored one. That saves all these
> > kind of problems.
> 
> You mean one should temporarily disable the watcher before filesave? But we 
> still have to reparse the "new" cmakefile and that will (currently) lead to a 
> reload of the cmake project's model as far as I saw in the sources. Hence 
> _all_ item's (below a given folder) get invalidated.

I guess currently thats true. However it shouldn't be needed at all in
theory. All thats "updated" with the parsing (thats not updated otherwise)
is the DUChain information, which the CMake support could also "manually"
update on such a change. But of course that means limiting what the user
can do in that editor window.
 
> > Another thing is that the cmake support should save the cmake file only
> > once he deleted all project items, not after deleting the first one or
> > even before that.
> 
> Yes, that would work as well of course, i.e. passing a QList of items. If the 
> project gets reloaded after all changes got applied, these things should work. 
> Though of course this does not guard against behind-the-back changes (VCS 
> updates, manual deletion, ....) in circumstances like I described in the 
> bugreport (i.e. deletion while a dialog is shown). There only refcounting or 
> globally disabling the watcher for that period would help.

Yeah, btw, what I actually meant was not refcounting the items, but what
David suggested. A Wrapper around items that you fetch if you want to store
an item for more than 10 ns and that wrapper you get only stores the path
in the tree. Then when you access the item again you can check wether the
path still exists and "do something apropriate" if it vanished.

Andreas

-- 
You will be advanced socially, without any special effort on your part.




More information about the KDevelop-devel mailing list