GNOME Bugzilla – Bug 309196
editing an image while a save or export is in progress can cause corruption
Last modified: 2018-05-24 11:34:11 UTC
This bug has been opened here: https://bugzilla.ubuntu.com/12235 "Steps to reproduce: 1) Create a large image (screenshot as png is fine for older hardware) 2) Open the image in the gimp and modify it 3) Click the window close cross in the top right hand corner - a dialog should pop up asking to save the changes 4) Click 'Save' 5) Quickly click the window close cross in the top right hand corner of the main gimp window 6) Click 'Discard changes' 7) Image is corrupted if the Discard changes was clicked before the previous save finished. This is counter-intuitive - if I'm in the middle of a save, the close window cross should bring up a dialog indicating a save is in progress - regardless whether I click close on the image window or the main window."
I am pretty sure we have a bug report on this for ages but I am unable to find it at the moment.
The culprit here is that we don't wait for the main loop to finish in app_exit_after_callback(). This slows down exit and might cause gimp to hang if plug-ins are still running. In the case of save plug-ins, this is probably desired, with other plug-ins it could be quite annoying.
This is also opened here: http://bugs.debian.org/330817 The problem in that report is only slightly different - the user hasn't modified the image, but wants to save it in a different format. So if the user closes the main GIMP window while the save is still in progress, the dialog with the Discard Changes window never comes up, and GIMP just quits immediately, only partially saving the file.
The bug report Sven is referring to in comment #1 is probably bug #145492, which is certainly related although perhaps not quite a duplicate.
Could you from your experience tell, if this is related to https://launchpad.net/distros/ubuntu/+source/gimp/+bug/36692 ? Or should I forward the bug separately?
That's a different problem that would be a duplicate of the bug that asks for locking. Cant find this bug at the moment...
*** Bug 387712 has been marked as a duplicate of this bug. ***
I can't believe that a so dangerous bug isn't fixed yet.. Isn't possible to lock/disable the painting area during saving?
*** Bug 524885 has been marked as a duplicate of this bug. ***
*** Bug 597663 has been marked as a duplicate of this bug. ***
We should really fix this and at least wait for save plug-ins to finish in the exit code.
*** Bug 618321 has been marked as a duplicate of this bug. ***
Me and mitch discusssed this a bit yesterday on IRC, let's move discussion on how to solve this here. Here's the current idea of a solution as I understand it: 1. Add a "locked" property to GimpImage. When an image is locked, it can't be modified. 2. Add PDB API to lock the image and make relevant plug-ins, in particular save plug-ins, lock the image while the image is being saved 3. In action updates, take GimpImage::"locked" into account and disable relevant actions, including "file-quit" 4. Make the GimpDisplayShell listen to this property and when set to TRUE, make the GimpCanvas insensitive (or something like that) 4. In gui.c, never exit until all images are non-locked Mitch, is this in line with your idea for a solution as well?
Just realized that is not good enough, we must handle crashing plug-ins that has a lock.
We should be able to handle that in gimp_plug_in_cleanup_image() though. If it sounds sane to at least one person more, I'll go ahead and make a patch.
I just figured that while using/extending the existing locked concept is the way to go, there are some subtle issues, let's discuss that on IRC again. Unrelated, why would the plug-in have to do the locking at all, that can be done more safely by the file saving mechanism in the core itself (unless I miss something here).
We won't have time to work on this for 2.8 if we want a release in 2010. Moving off milestone. We can put it back if someone magically starts giving us patches.
My current way to look at this problem is that this is an effect of a fundamental design problem. Plug-ins and the core run concurrently and use an API that is not designed for concurrent usage. We should either make our API safe for concurrent usage (hard) or we by design makes it impossible for plug-ins and the core to run at the same time (easier). Won't have time to do that for 2.10 (3.0) though, putting on Future milestone...
Thank you for this information Martin. This bug is now on Launchpad https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/18505.
*** Bug 774026 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/153.