GNOME Bugzilla – Bug 148997
Text layer rendering leaks font file descriptor
Last modified: 2004-09-21 22:42:37 UTC
Symptom: After having GIMP running for a few days and doing some work involving text layers now and then, suddenly many actions fail with a "too many open files" error message, among them trying to save your work (which is why I classify the bug as "major"). Apparent cause: It seems that every time a text layer has to be re-rendered because the text changed, the corresponding font file is newly opened, but not closed afterwards. After a while, a limit of open file descriptors is reached (256 for me), and the mentioned error messages appear. Steps to reproduce: Make a new text layer and type some text. Run 'lsof -c gimp-2.0' in a terminal to see a list of open file descriptors. Make some changes to the text and run lsof again. Observe that for each re-rendering of the text, a new file descriptor pointing to the same font file has been opened. These are some sample lines from the lsof output: gimp-2.0 14481 cwalther 57r VREG 14,9 65932 3354867 /Users/cwalther/Library/Fonts/ Vera.ttf gimp-2.0 14481 cwalther 58r VREG 14,9 65932 3354867 /Users/cwalther/Library/Fonts/ Vera.ttf gimp-2.0 14481 cwalther 59r VREG 14,9 65932 3354867 /Users/cwalther/Library/Fonts/ Vera.ttf
Thanks for your report. This problem was already known and reported as bug #138882. It seems that the cause may reside in the Pango library. I think that leaving this bug open may help other reporters in looking for duplicates. Anyway it's interesting to know that Mac is another affected platform. Could you please post your OS details? I don't know how (if possible at all) to look that field in Bugzilla. Note that under Linux the file is properly closed, as can be easily seen with: strace -e trace=open,close gimp-2.0
Ah, I only looked for open bugs on GIMP, so I missed the ones on Pango. I'm using Mac OS X 10.3.4 and Gimp.app 2.0.3-2, which includes all necessary libraries and stuff. Pango versions are as follows, do you need any other libraries' versions? cwalther$ ls -l Gimp-2.0.3-2.app/Contents/Resources/lib/ | grep -i pango -rwxr-xr-x 1 cwalther admin 307648 22 Jul 02:24 libpango-1.0.0.399.1.dylib lrwxr-xr-x 1 cwalther admin 26 30 Jul 12:29 libpango-1.0.0.dylib -> libpango-1.0.0.399.1.dylib -rwxr-xr-x 1 cwalther admin 221048 22 Jul 02:24 libpangoft2-1.0.0.399.1.dylib lrwxr-xr-x 1 cwalther admin 29 30 Jul 12:29 libpangoft2-1.0.0.dylib -> libpangoft2 -1.0.0.399.1.dylib -rwxr-xr-x 1 cwalther admin 55660 22 Jul 02:24 libpangox-1.0.0.399.1.dylib lrwxr-xr-x 1 cwalther admin 27 30 Jul 12:29 libpangox-1.0.0.dylib -> libpangox -1.0.0.399.1.dylib -rwxr-xr-x 1 cwalther admin 26196 22 Jul 02:24 libpangoxft-1.0.0.399.1.dylib lrwxr-xr-x 1 cwalther admin 29 30 Jul 12:29 libpangoxft-1.0.0.dylib -> libpangoxft -1.0.0.399.1.dylib drwxr-xr-x 3 cwalther admin 102 22 Jul 02:29 pango ktrace, which seems to be BSD's equivalent to Linux's strace, also shows that the file is opened but not closed. Addition: On doing some more experiments, I've found that it doesn't happen with all fonts. It seems to happen with those coming from .ttf and .pfb files, but not with .dfont files and font suitcases.
It seems that the problem exists in the Pango FreeType backend, and that would explain your findings. See bug #138882 for more details.
Created attachment 30154 [details] [review] GIMP workaround for pango fontmap leak (bug 143542,138882,148997) I created a workaround for this bug / bug 138882 mostly for personal use because it limits the usefulness of the text tool on Windows. I attach a patch here in the hope that it may be useful to others (who compile The GIMP themselves) too. The patch (for the source code) works by keeping a reference to the fontmap and clearing its cache before the last reference is released, thereby breaking the circular reference and allowing it to be released so the font file is closed properly. It works fine for me using latest gimp-2-0 and pango-1-4 on Windows XP. It is not platform-specific so it should work on other OS:es too. Just maybe the GIMP maintainers could consider including it in 2.0.4 unless the Pango bug is fixed before that?
Yes, most of my comment in bug #138882 comment #25 was bogus; the only meaningful thing was to point out that even under Linux there was a leak, even if it manifests itself in a different way. That's why I apologize. Thank you very much for the workaround.
Could you please consider including the supplied workaround in 2.0.5? This bug significantly limits the usefulness of the text tool on Windows. See also Owen's recent comment in bug #143542 regarding fixing the underlying Pango bug. (Setting target milestone to 2.0.5 as requested on the gimp-developer list)
Oh, there's a workaround. Well, someone should have set the PATCH keyword then.
Created attachment 31799 [details] [review] same workaround, implemented using a weak reference Could you perhaps test this patch? It should basically do the same as what your patch is doing, just by using a weak reference and gets away without a custom callback function. If this works for you, I'll apply it to both branches (the patch applies cleanly against the gimp-2-0 branch also).
Yes, your patch works fine for me with gimp-2-0. Your patch is really elegant by the way, hats off!
Committed to both branches. Thanks a lot for contributing this nice workaround and please excuse that I didn't look at it earlier. 2004-09-22 Sven Neumann <sven@gimp.org> * app/text/gimptextlayout.c (gimp_text_get_pango_context): workaround Pango bug #143542 (PangoFT2Fontmap leak, see also bug #148997). Based on a patch by Robert Ögren.