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