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)

[Kenichi Handa]

In article <4A005A64.5050908@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> 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.

Oops, I've just fixed this typo:
  font_sort_entites -> font_sort_entities
Anyway, font_sort_entities is called from
font_find_for_lface (via font_select_entity).

Could you please find why font_find_for_lface is called so
releatedly by setting breakpoint in fontset_find_font (with
condition "c == 0x2203)?

> 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.

SAFE_FREE surely calls xfree via unbind_to because
SAFE_ALLOCA calls record_unwind_protect with
safe_alloca_unwind.

---
Kenichi Handa
handa@m17n.org