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 767719 - Gimp not closing after processing large files
Gimp not closing after processing large files
Status: RESOLVED INCOMPLETE
Product: GIMP
Classification: Other
Component: General
2.8.18
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2016-06-16 07:21 UTC by Klaus
Modified: 2018-01-05 19:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GEGL's tile cache moves from singly-linked lists to hash tables, making loading and closing several times more efficient (6.79 KB, patch)
2016-06-21 16:27 UTC, Martin Pelikán
committed Details | Review

Description Klaus 2016-06-16 07:21:35 UTC
Since upgrading to 2.8.16 I noticed that Gimp does not close at all or closes only after a very long time (>15min) after I had processed and closed a large file (20,000 x 10,000pxls).

Checking Task Manager it uses about 25% CPU and releases memory very slowly in small steps, i.e. the window appears to be frozen but tends to recover after a very long time, sometimes up to 30min.

This only happens after closing the file, Gimp does not have any issues processing these files with filters or exporting etc.

I experience the same on 2 machines with Win7 64bit, one with 8GB the other with 16GB RAM. I'd assume it is a problem with memory handling.
Comment 1 Michael Schumacher 2016-06-21 07:44:28 UTC
Is it enough to just open such files and close them again?
Comment 2 Martin Pelikán 2016-06-21 14:24:23 UTC
I've reproduced this a couple of days ago and pointed it at g_slist_remove from the GEGL tile cache (as mentioned on IRC).  Hundreds of thousands of memory references are done per tile, taking from 1 to 50ms each.  That linked list shouldn't probably be there at all, or use more efficient code that only swaps pointers instead of doing a search.  Working on a fix.
Comment 3 Martin Pelikán 2016-06-21 16:27:31 UTC
Created attachment 330145 [details] [review]
GEGL's tile cache moves from singly-linked lists to hash tables, making loading and closing several times more efficient

I meant 1-50ms per g_slist_remove(), not per each memory access (no swapping was involved).

This patch makes things a lot better for me.  I reckon it's a good start.
Comment 4 Michael Schumacher 2016-06-22 07:34:14 UTC
This isn't platform-specific, is it?
Comment 5 Martin Pelikán 2016-06-22 10:54:30 UTC
No.  I was testing it on amd64 Gentoo Linux with -O3 -march=native and the patch only uses standard glib constructs.
Comment 6 Øyvind Kolås (pippin) 2016-06-22 13:49:49 UTC
Review of attachment 330145 [details] [review]:

The patch has been committed - but is probably also not the cause of the original bug report, since GIMP-2.8 did not use GeglBuffers for neither its layers nor loading.
Comment 7 Klaus 2016-06-27 00:57:53 UTC
(In reply to Michael Schumacher from comment #1)
> Is it enough to just open such files and close them again?

Opening the file and closing it without any changes does not cause the issue, memory is released instantaneously.

Playing around with some of the usual processing steps I found the issue occurs if I increase saturation, export the file to JPG and then close without saving the changes.

Other filters or modifications I usually use don't appear to cause the problem.
Comment 8 Klaus 2016-08-23 11:14:27 UTC
Just update to version 2.8.18 and found that the problem persists.
Comment 9 Klaus 2016-08-23 11:16:57 UTC
Just updated to version 2.8.18 and found that the problem persists.
Comment 10 Klaus 2016-08-27 02:09:32 UTC
Just noticed that not only the closing function is affected but also scaling. 
After adjusting the Saturation of a 20,000x10,000 pxl image via Colors-Hue-Saturation, the scaling function pretty much becomes unresponsive, it may eventually complete but can take up to 15 minutes or longer.

I believe the function Colors-Hue-Saturation is causing issues that subsequently slow other Gimp functions down to a degree that it appears to be frozen.
Comment 11 Michael Natterer 2018-01-01 23:14:48 UTC
I doubt that we will change anything in 2.8 memory management.

Klaus, can you check if the issues are fixed in git master?
Comment 12 Klaus 2018-01-05 19:52:53 UTC
My apologies but I had to replace my laptop and do no longer have this problem since doubling my RAM.
Comment 13 Jehan 2018-01-05 19:57:32 UTC
Let's close then, I guess.
If ever this problem happens again, please feel free to reopen this bug report.
Thanks.