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

Full log

Message #109 received at 3208 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: schierlm <at> gmx.de, 3208 <at> debbugs.gnu.org
Subject: Re: 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: Fri, 26 Jun 2009 22:12:38 +0900

In article <4A44629C.9040209 <at> gnu.org>, Jason Rumney <jasonr <at> gnu.org> writes:

> Kenichi Handa wrote:
> > If no GC happens while displaying all characters of that
> > long line, those temporarily created Lisp vectors accumulate
> > in memory without reused, which may lead to memory full.
> >   

> While I was profiling to try to identify a possible cause, there were 6 
> GCs in the 25 seconds that Emacs was running (taking up 22% of the 
> time). So GC does seem to happen, though maybe it was after the first 
> warning was thrown.

I added a static variable `vconcat_size' that accumulates
the size of vectors created by Fvconcat at the end of
font_list_entities.  After (insert-char #x2203 10000), GC is
called once while update_menu_bar is called.  After that,
until memory_full is called (in the Fvconcat above), no GC
is called, and vconcat_size increases by about 100M which
means at least 400M bytes is consumued by dead vectors.

So, I think the above hypothesis is correct.

---
Kenichi Handa
handa <at> m17n.org

Previous Next

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