[E-devel] ["Guy.Bormann" <guyb@uia.ua.ac.be>] [Cooker] Serious imlib bug in some 1.9.x versions

[Vox <vo...@th...>]

       Just saw this on the mandrake cooker mailing list, thought
       somebody here may want to take a look at it.

From: "Guy.Bormann" <gu...@ui...>
To: <co...@li...>
Subject: [Cooker] Serious imlib bug in some 1.9.x versions

!!Sorry, template message ahead!!
-------------------------------------------------------------
Hello,

There is a potentially serious problem with (lib)imlib for versions up to
and including 1.9.13 that crept in probably around 1.9.9 or 1.9.10
(haven't checked but it was probably first introduced between image loader
module support and the disabling of helper image loader processes). I am not
familiar with the maintenance organisation of imlib so this message is
posted to the major Linux bleeding-edge distros (I checked RedHat RawHide1.0
imlib-1.9.13-3.7 source). I couldn=B4t query the Bugs DB, so I apologize if
it is already known (it is, it is fixed in 1.9.14, and probably all SuSe
releases).
  I include a simple fix, not a patch since version 1.9.14 (ximian
release) has a complete cleanup of the helper process support and
recognized the problem. (It is a silent fix (i.e. no ChangeLog entry)
since it exposes big mouthing by the author/maintainer about "this is
2002"... ;-) (Bugzilla hates me, not able to check bug#'s.)

Symptoms: on my system (Mandrake 8.0 with major 8.2 Cooker upgrades):
  anjuta complains after a while about too many open files for a single
    source and doc file project.
(same thing could have happened to my RedHat 7.1 home system but I didn't
upgrade yet (=3D=3D>pacifier for distro-cross posting :-P )
Diagnostics:
  lsof shows that it is constantly reopening theme image files without
    closing them, pointing toward the gtk libpixmap (I use DarkMarble ;-)
    theme engine (or any other engine using libgdk_image) and thus
    pointing to libgdk_imlib
  due to this, I also checked other gtk apps : gnomecc, gimp, gedit, ...
    showed the same behaviour
Why did only anjuta get sick?
  It has a new feature (as of v1.8) : whenever a open doc in the editor
    changes due to C/P or typing, the color of the notebook widget page
    label changes.
  Anjuta does this by setting a theme color rc and issueing a gtk_rc_style
    reload.
(Mmm, that's weird, I have imlib caching enabled which should generate
hits for every gtk-widget opened or gtk_rc_style reloaded, inter-appl.-wide,
instead it reopens files...Ok, that's something else for the imlib
maintainers...)  Other apps. only happen to create widgets (and thus gtk
theme loads) once in a while (you need to open between 20-30 widgets to
hit a limit of 1024 for an average theme).

Prognosis: Ok, but potentially dangerous (imagine minor scattered changes
to 10 source files in anjuta before the autosaver kicking in (and changing
the label) when you only have 10 fd's left).

Treatment : either fix Cooker imlib-1.9.13-1mdk sources at around line 305
of gdk_image/load.c (i.e. the unconditional "#if 0" should only exclude
the "else {...}" clause of the "if (!need_conv || !data) {}" to allow file
closing for non-EIM format files) or kick Cooker up to 1.9.14 of imlib.

Sorry for this hefty mail, but this way people can recognize the bug as it
is only apparent in gtk apps. with heavy image loading such as anjuta or
thumb nailers/animators.

Guy Bormann

SuSe imlib's don't seem affected (checked 1.9.9-100 and 1.9.10-1)
Checking Debian as of now...
-----------------------------------------------------------------