|
From: | Jason Rumney |
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, 05 May 2009 23:25:24 +0800 |
User-agent: | Thunderbird 2.0.0.21 (Windows/20090302) |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |