GNOME Bugzilla – Bug 138882
multiple text layers eventually use too much memory and crash gimp
Last modified: 2004-12-22 21:47:04 UTC
0. Open Windows Task Manager and look at the Mem Usage of gimp-2.0.exe 1. Open a JPG image 2. Select the Text Entry Tool 3. Click on the image and enter in some text 4. Erase what you wrote and enter in another string 5. Repeat step 3 and 4 until the gimp eventually exits. On my machine, it exits at around 108 MBs of mem usage (on a Pentium-M 1.3, 512 MB ram, 270 available). Actually, changing font size or changing the color will also contribute to the memory increase and and eventual crash of the app.
If your operating system kills an application that uses approx. 100MB of memory, then it's about time to look for a different operating system. There is really nothing we can do about the brokeness of Windows. Please run GIMP from a text console and check if there are any warnings or other messages before GIMP exits. Unless you provide more info, there's nothing we can do about this. Also, what size did you configure for the tile-cache? Does your harddisk have enough space to hold GIMP's swap file? How large are your undo limits configured?
Just for the record, I've run another valgrind session and checked the text tool and especially text undo for memory leaks. There are none.
I can reproduce this with GIMP 2.0.2 and GTK+ 2.4.3. Maybe this leak just happens on Win32 and/or in one of the libraries used for font handling.
AFAIK, the same libraries are used for font-handling on all platforms.
I am also able to replicate this bug. WinXP Pro, 512ram, dual display, Jernej installer, gimp 2.0.2, GTK+ 2.4.1. Also it might not be the data in the text field. Every character and backspace/delete I press adds about 144k to ram. But if I use Ctrl-V to paste in several lines of text only adds about the same as if I just type in one character. XP does not appear to be closing the program, I'm able to use programs well over 400,000k without closing (openning ut2004 beta installer 204meg in notepad). Does exit out about 70-100,000k. Windows does not report that gimp or plugins have crashed. Actually after slowing my system down I'm able to catch a console window opening and screenshot it, it states: ** (gimp-2.0.exe:2200): WARNING **: Unable to open font file C:\WINDOWS\fonts/21205___.TTF for font Bitstream Vera Sans 14, exiting I was using the default "Sans" font in gimp. The ttf file does exist on my system and is the "Jokerman LET Plain:1.0 (TrueType)" which is not the font I was using.
The memory that is added with each modification goes to the undo stack. You shouldn't see the memory used by GIMP climbing without bounds since at some point the undo stack will be filled and old undo steps are freed. So I don't think that we have a memory leak here. It rather looks like there's still a problem with Pango/FontConfig/FreeType not being able to handle broken(?) fonts.
I asked the original bug reporter about the configured tile cache size and undo limits and I am still waiting for a reply to this question.
I did a longer session with valgrind, a memory debugger, searching for memory leaks. I found a minor one in the text tool code but it was certainly not the cause for this problem. Could you please open the undo history and check what undo steps are created when you edit text. Unless you type very slowly, you shouldn't see a new undo step being pushed for each character you type. Subsequent text edits are supposed to be compressed unless there's a delay of more than 3 seconds. Does this happen for you?
I can reproduce this as well with Windows 2000. The problem seems to be a handle leak as the error message reported in comment #5 suggests. Every time a character is entered a new font file is opened, as revealed by Process Explorer from <http://www.sysinternals.com>. I haven't tried to find where the handle is leaked; it may be either gimp, pango, fontconfig or freetype.
A leaked file-descriptor would indeed explain the problem. I doubt however that the file-descriptor is leaked in GIMP since GIMP doesn't see the font files at all. If we would leak a Pango or FreeType struct that holds the file descriptor, then valgrind should have shown that.
Min undo levels: 5 Max undo levels: 4megs Tile cache size: 64megs conservative mem usage unchecked (believe this is default settings) I am able to jump from about 28,000k to over 90,000k and "crash" with just 3 undo levels: [Base Image], Add Text Layer and Text by holding down "a" with a few enters all without a 3 sec pause. Undo appears to work correctly with a 3sec pause as you described. I will attempt to setup a seperate font folder for gimp and a limited set of fonts for it after work. Will also try with and without Wimp support (which might make me jump to gtk+ 2.4.3 if that is ok)
This sounds like the fontconfig cache is non-existant on your computer. The fonts shouldn't have to be reloaded over and over again. Perhaps it's just the installer that failed to generate the fc-cache.
if you mean the ".fonts.cache-1" file it is used and working. In the past there was an issue with Jernej's installer which had a problem with this file and it took about 1-2min to load Gimp reading all the fonts, with this file it takes under 30sec to startup. Renaming the file temp causes the same startup slowdown. Also able to replicate file handles in Process Explorer and filemon. Every added or removed character shows a new file handle to C:\Windows\Fonts\vera.ttf and file mon reports that the file is opened and read but not closed.
Tried a fresh install of Jernej's gtk+ 2.4.3 and gimp 2.0.2, making sure that the gtk+, gimp, .gimp-2.0, .thumbnails and .fonts.cache-1 directories/files are gone. I also tried not installing with Wimp and freetype options without luck, problem still exists. Does it seem to still be worth for me to try to make a seperate font directory for testing?
You say that "every added or removed character shows a new file handle to C:\Windows\Fonts\vera.ttf". Is that the font that is used to render the text layer or is that the font that is used in the text editor window? Is a different font file leaked if you change the text layer's font?
The font I choose to render in the image is the one that leaks. The text editor font does not change and is not the fonts I have choosen. Also if I change fonts it will still keep all the previous fonts handles.
I am guessing but from what I know about this code I'd say that the problem is most likely in the FreeType library then.
The FreeType library is almost certainly the one which is opening the file. The question is which one is neglecting to make the call that closes it (it may be FreeType, or maybe not). Almost certainly too, it's not gimp, since this only happens under Windows and I guess (have not checked) that there's no platform-specific code in that section. The question then is whether the problem is in Pango or not, from Bugzilla's point of view, in order to decide on whether to reassign it or to close it as NOTGNOME. Of course, similarly to bug #132366, since the problem was detected with GIMP it would be good to follow the cause down to its root and report it.
I get this problem as well, using gimp-2-0 and gtk-2-4 from CVS on Windows XP. To make it easier to track it down I managed to extract a small test program from gimptextlayout.c that reproduces the problem. The program repeatedly creates a PangoLayout and then releases it. When I link the program against glib-2.4.1, pango-1.4.0, fontconfig-2.2.2-20040201 and freetype-2.1.7-1 (the binaries from http://www.gimp.org/~tml/gimp/win32/downloads.html), I get a leaked handle each time the test function gimp_text_layout_new_test is called. This can be observed for example by turning on the handles column in the task manager on Windows XP. Both the memory usage and handles increase each second while the program runs. If the call to pango_layout_get_pixel_extents is removed there is no handle leak.
Created attachment 29567 [details] Test program for font file handle leak on win32 Test program in c, link with glib, freetype, pangoft2 and fontconfig
This should be good enough to pass the bug-report further down to Pango then.
*** Bug 141559 has been marked as a duplicate of this bug. ***
I have now reassigned this bug report to Pango since it seems that the problem is somewhere down the line of libraries involved in font rendering. There's a small testcase attached that allows to reproduce the problem on win32. If the Pango developers think that the problem is certainly not in their code, the bug should be assigned to fontconfig and finally freetype. It would be helpful to get detailed version informations for the fontconfig and freetype libraries used in the win32 build of GIMP.
The test program leak is a duplicate of bug 143542 I'm pretty sure. If there is actually a platform-specific leak that would have to be investigated separately. *** This bug has been marked as a duplicate of 143542 ***
After examining the situation more carefully there doesn't seem to exist a platform-specific leak, just a change in the way of doing things. Under Linux what is leaked is a mmap() call which is never munmap()'ped; this is characteristic of builds/unix/ftsystem.c in the Freetype source. Regardless of the details of how the leak manifests, the point is that a FT_Face handle reserved via FT_New_Face is never freed. This is a backtrace taken at the last caller to the leaked FT_New_Face:
+ Trace 49029
For what I see, the problem is unrelated to bug #143542; it is the lack of implementation of pango_ft2_font_real_unlock_face to free what the _lock_ counterpart reserved. With that in mind, here's the patch that I've come with, taken against Pango 1.4.0 (it may still miss something). If my understanding of the situation is correct then this bug might need to be reopened. diff -pur pango/pangoft2.c~ pango/pangoft2.c --- pango/pangoft2.c~ 2004-08-02 02:50:56.000000000 +0200 +++ pango/pangoft2.c 2004-08-02 02:56:36.000000000 +0200 @@ -614,6 +614,13 @@ pango_ft2_font_real_lock_face (PangoFcFo static void pango_ft2_font_real_unlock_face (PangoFcFont *font) { + PangoFT2Font *ft2font = (PangoFT2Font *)font; + + if (ft2font->face) + { + FT_Done_Face (ft2font->face); + ft2font->face = NULL; + } } Actually there's another place within the GIMP where another leak of the same kind is happening, namely in gimptext-bitmap.c (gimp_text_render_bitmap). The font opened via pango_ft2_font_get_face() is not closed via FT_Done_Face(). Perhaps the correct function to call from there is pango_fc_font_lock_face() instead, using its _unlock_ counterpart to close it (when fixed)?
Oh, I think that I'm starting to get the picture. That's what happens when you look at the low level stuff without a global view and no real knowledge of how it works. My apologies for that.
Owen is right - this is caused by bug 143542, and it's not platform-specific. The workaround described by Morten in bug 143542, clearing the fontmap cache of a fontmap before releasing it, seems to work for the GIMP as well. I have posted a patch for the gimp-2-0 source that implements this workaround in bug 148997, maybe it could be useful. At least it fixes the leak for me (Win XP, pango-1-4, gimp-2-0).