From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.18-10mdk i686) Description of problem: This version of libgdk_imlib does not close opened files due to an overeager cleanup operation of the helper process code in gdk_imlib/load.c. It causes symptoms that are extremely hard to relate with gdk_imlib. (I initially thought it was an anjuta 1.x (x >= 8) problem, then a gtk/gdk problem, then a gnome problem, then a gtk-engines problem to finally arrive at imlib.) This is another very good reason to ditch the 1.9.x (9 +/-< x <= 13) version and move RawHide to 1.9.14. Due to its seemingly unrelated symptoms it might also be useful to spread some rumor among early adopters. (For a more detailed analysis : see attachment) BTW, the problem is completely recognized and straigthened out in 1.9.14. I hope this is not old new... Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. fire up anjuta 1.8/1.9 2. use it for a while with a lot of typing/saving sequences 3. (leave on autosaving, a lot of document state changes are necessary) (For a clarification of point 3. see the attachment.) Actual Results: Anjuta pops up a dialog, signalling a "system error:too many files open, Cannot save" type of message. lsof|grep anjuta confirms this during such a session. Studying the output of lsof|grep anjuta learns that is image files that stay open, most notably gtk theme image files (i.e. icons). Also the GIMP and any other gtk/gdk-app. is affected. Expected Results: Anjuta should not have complained about too many open files for a limit of 1024 and with a small single source and doc file project open. (In fact, gdk_imlib should load the images from the cache anyway, which doesn't happen although the image cache is enabled with imlib-config!) Additional info:
Created attachment 54604 [details] complete analysis from Symptoms to Treatment
I believe this is fixed in imlib 1.9.14
The 1.9.13-3.7.x version in Rawhide has this bug fixed. The changes in 1.9.14 compared to this are some configure improvements (no difference to the end product) and some code cleanup.
It is but it is nowhere mentioned, not even in the ChangeLog. If you don't know it, you won't find it without following the chain from your gtk-app down to libgdk_imlib in the sources. Especially the combination with anjuta (see attachment for an explanation) makes it an at the least annoying bug. But you can considered it closed if you like. Most RawHide'rs are probably able people to diagnose it themselves (if they have 1.5 days to spend :o). I just posted it for reference.
Not mentioned in the ChangeLog? * Wed Apr 10 2002 Owen Taylor <otaylor> - Backport file descriptor leak and extra waitpid fixes from 1.9.14
(I should say, I do understand appreciate that you spent the time tracking down the problem, and the annoyance of spending a lot of time tracking down a problem, then realizing that someone else has already fixed it and you were working with an old verison. I'm just pointing out that the Rawhide version of imlib does already have a fix for this.)
Ok! Ok! Mea culpa! :o) Turns out, of all the source packages I checked (to have an idea on around which version this overfix turned up), I only checked the root ChangeLog instead of the gdk_imlib ChangeLog of the RawHide version or I must have gotten hold of a slightly older version and forgot to pay attention to that little !!!!!x!!!!! in 1.9.13-3.7x. BTW, SuSe seems to have it fixed in their 1.9.9 already...(they're still at 1.9.10 but what do minor version numbers mean nowadays...) Is it so commercially vital to keep major fixes in-house? (Rhetorical question, and besides, obviously the wrong forum to ask...) Anyway, I think we can leave it at this! Thanks for your time and for staying polite :o)