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

[Milian Wolff]

On Monday, 4. January 2010 14:43:00 Andreas Pakulat wrote:
> 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 :)

Yes, that would work in this case I think. But I'm still in doubt in regard to 
deletion of nested directories, but this should be easy to detect I think.

> > > 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.

I'd personally don't want to limit the user in what he can do. Esp. 
considering that I doubt it would be easy with the KTextEditor API (afaik 
there is no such thing as "drag selection" events or similar).

> > > 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.


-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100104/70f3ed07/attachment.sig>