GNU bug report logs - #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)

Previous Next

Packages: w32, emacs;

Reported by: Michael Schierl <schierlm <at> gmx.de>

Date: Mon, 4 May 2009 18:35:03 UTC

Severity: normal

Done: Jason Rumney <jasonr <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Kenichi Handa <handa <at> m17n.org>
To: Jason Rumney <jasonr <at> gnu.org>, 3208 <at> debbugs.gnu.org
Cc: schierlm <at> gmx.de
Subject: 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)
Date: Tue, 19 May 2009 11:13:31 +0900
In article <4A005A64.5050908 <at> gnu.org>, Jason Rumney <jasonr <at> 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 <at> m17n.org




This bug report was last modified 15 years and 308 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.