Op den Dingsdag, de 18. September 2012 Klock 23:17:53 hett Chong Yidong 
schreven:
> Eli Zaretskii <eliz@gnu.org> writes:
> > Can anyone else reproduce this?
> 
> I can reproduce this.  On bisecting, the problem first shows up with
> 
>   revno: 104186
>   fixes bug: http://debbugs.gnu.org/8640
>   committer: Juanma Barranquero <lekktu@gmail.com>
>   branch nick: trunk
>   timestamp: Tue 2011-05-10 12:31:33 +0200
>   message:
>   src/image.c (Finit_image_library): Return t for built-in image types.
> 
> A quick glance at the diff of this revision does not reveal immediately
> why it causes the problem, though.

I have no idea why that revision triggers the bug either, but here is a patch 
that fixes the problem. I have no idea if it matches your quality standards, 
but I think it is clean enough. I've reused and adapted some code already 
present for Win32 (which is the reason they don't suffer the same problem).

The linked list `image_types' grows without bounds because 
CHECK_LIB_AVAILABLE/define_image_type never checked if the given image type is 
already in `image_types'. My lisp code triggered tons of `Finit_image_library' 
calls. Since the list is searched linearly at some point, that explains the 
run-time impact.

I have no idea what was originally supposed to ensure `image_types' doesn't 
include duplicate entries, so the patch may be way off... hope someone actually 
knows what is suppsed to go on there.

-- 
CU
	Jörg