bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32)

[Jason Rumney <jasonr@gnu.org>]

Michael Schierl wrote:
> - It is easier if you have one of the fonts Code2000 or Arial Unicode
>   installed. I tried it with fonts that come with Windows XP (like
>   Lucida Sans Unicode) but did not succeed in reproducing the bug.
>   It might happen with other fonts as well, most likely ones that have
>   lots of glyphs.
> - You need to know a character that is in your font but not in the
>   default font (0x2203 works for both Arial Unicode and Code2000, 0x2202
>   would work for Lucida Sans Unicode, 0xFFFD works for Arial Unicode).
> - Start emacs -Q
> - Insert a few thousand characters of that kind, and move to the
>   beginning and to the end of the buffer repeatedly. At first you
>   receive warnings like "Emergency (alloc): Warning: past 95% of memory
>   limit", then the memory is exhausted, and if you still go on, you will
>   be asked if you want to debug Emacs. This is perfectly reproducable
>   for me, both on my main machine and on a freshly installed WinXP
>   virtual machine where I only added Emacs and one of the fonts.
>   

I can reproduce this. The malloc warnings always seem to occur in the 
SAFE_ALLOCA call in font_sort_entities. The vec passed in to that 
function contains all the fonts on my system, and len is over 3000, 
requiring 24kB to be allocated. There appear to be two bugs here.

One is that this function is being called all the time when we have 
already found a font for the character we added to the buffer.

The other is that SAFE_FREE does not appear to call xfree to free the 
memory that SAFE_ALLOCA allocated with xmalloc. Maybe SAFE_ALLOCA is not 
used often to allocate more than 16kB (the threshold for using the heap 
instead of the stack) so this has gone unnoticed in the past.