After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 8141 - cancelling a plug-in may leave dangling images around
cancelling a plug-in may leave dangling images around
Product: GIMP
Classification: Other
Component: Plugins
git master
Other All
: Normal normal
: Future
Assigned To: GIMP Bugs
: 690512 (view as bug list)
Depends on:
Reported: 2000-03-31 04:10 UTC by kelly
Modified: 2018-05-24 10:28 UTC
See Also:
GNOME target: ---
GNOME version: ---

attempt to delete temporary image from quit handler (3.90 KB, patch)
2006-06-21 11:04 UTC, Sven Neumann
needs-work Details | Review
give upto 1 second (in 1/10 second intervals) for plug-in to die after GP_QUIT is sent (1.81 KB, patch)
2006-09-26 19:29 UTC, Mukund Sivaraman
rejected Details | Review

Description kelly 2001-01-28 15:50:17 UTC
Package: gimp

Cancelling the warp plugin sometimes leaves the temporary images
created to hold the displacement maps laying around.


------- Additional Comments From 2000-12-09 12:29:15 ----

Subject: Re: cancelling warp plugin leaves tmp displacement map images around
From: Sven Neumann <>
Message-Id: <>
Date: 09 Dec 2000 18:29:15 +0100


I'm afraid we can not easily do something about this problem with the
current design of plug-ins in the gimp. The plug-in would need to register 
a quit function that aborts the running calculation, then cleans up. Since
Gimp gives us only 10 ms before it kills the plug-in after sending quit
through the pipe, it would be very difficult to implement this properly.

I'll set severity of this bug-report to wishlist.

Salut, Sven

------- Bug moved to this database by 2001-01-28 10:50 -------
This bug was previously known as bug 8141 at
Originally filed under the gimp product and general component.

The original reporter ( of this bug does not have an account here.
Reassigning to the exporter,
Reassigning to the default owner of the component,

Comment 1 Raphaël Quinet 2001-04-26 18:14:21 UTC
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Comment 2 Michael Natterer 2001-06-19 00:52:16 UTC
Assinged to current CVS because it's a still unresolved problem.
Comment 3 Alan Horkan 2003-07-23 18:41:57 UTC
Changes at the request of Dave Neary on the developer mailing list.  
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone.  Hope that is acceptable.  
Comment 4 Sven Neumann 2004-11-15 10:30:15 UTC
Now that there's a stack frame of procedure calls in the GIMP core, this could
actually be implemented. GIMP should track the creation of core objects and
remove any unattached items when the procedure finishes (doesn't really matter
whether it was killed or quit by itself).
Comment 5 Sven Neumann 2006-06-06 10:45:20 UTC
Is this still reproducable with the current code?
Comment 6 Sven Neumann 2006-06-21 10:04:43 UTC
Yes, just reproduced this with current CVS.
Comment 7 Sven Neumann 2006-06-21 11:04:31 UTC
Created attachment 67778 [details] [review]
attempt to delete temporary image from quit handler

Just for the fun of it, I tried to delete the temporary image from the quit handler. The quit() function is called, but for some reason the call to gimp_image_delete() doesn't seem to have any effect. The problem is probably that the core never gets the message because the plug-in is killed directly after the quit function is being called.
Comment 8 Mukund Sivaraman 2006-09-26 19:29:55 UTC
Created attachment 73452 [details] [review]
give upto 1 second (in 1/10 second intervals) for plug-in to die after GP_QUIT is sent

(Sven: Sorry if this's not the right place to post the patch, but I wrote it for this particular issue.)

Basically the patch increases the time delay to 1 second, while checking every 1/10 seconds if the plug-in has already died and exiting the loop early (and hence not blocking the app if everything is ok). So a plugin will get upto a second before it gets killed, and if it wants to, it can clean up. I applied Sven's patch as well to the warp plug-in and it seems to get enough time to clean up now.

I hope this is not a bad idea.
Comment 9 Mukund Sivaraman 2006-09-26 20:55:42 UTC
Mitch explained to me that the app is blocked while waiting and the plug-in can't talk to it at that time. So this idea is borked. Please ignore the last patch.

Comment 10 Sven Neumann 2008-06-05 08:51:53 UTC
The idea that was outlined in comment #4 doesn't work. At least not without some additional API. The core currently does not know if an unattached image (an image that doesn't have a display) is just some junk left by a broken script or plug-in or if it is important. We would have to add an API that allowed a plug-in to tell GIMP that it creates a temporary image that should not be kept around when the plug-in exits.

Alternatively we can try to follow the approach from comment #7. That would need a change in the core to do a non-blocking wait for the plug-in to quit.
Comment 11 Sven Neumann 2008-10-07 21:42:26 UTC
Cancelling the PDF import plug-in is another way to run into this bug. When opening multiple pages as images, the plug-in first opens the images, then goes through the list of images and creates displays for them. If you cancel the plug-in, the images are still loaded, they just don't have displays created for them. To the user who is not aware of this (and the possibility to delete the dangling images from the "Images" dockable) this appears as a massive memory leak.
Comment 12 Michael Natterer 2013-02-07 10:23:37 UTC
*** Bug 690512 has been marked as a duplicate of this bug. ***
Comment 13 Michael Schumacher 2016-05-31 21:29:23 UTC
We still got a reviewed patch attached here - but the last few comments hint that it didn't work, right?
Comment 14 GNOME Infrastructure Team 2018-05-24 10:28:10 UTC
-- 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: