Bug 8633

Summary:	fc-cache memory usage is huge
Product:	fontconfig	Reporter:	Dan McMahill <dmcmahill>
Component:	fc-cache	Assignee:	Keith Packard <keithp>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	blocker
Priority:	high	CC:	dhalik
Version:	2.4
Hardware:	SPARC
OS:	Solaris
Whiteboard:
i915 platform:		i915 features:
Attachments:	font files which trigger excessive memory usage

Description Dan McMahill 2006-10-13 10:53:00 UTC

Hello,

I've been having some problems with fontconfig-2.4.0 on solaris 9/sparc.  What I
found was "fc-cache -f" would end up using something like 1.5 Gb of virtual
memory and on a machine with only 512 Mb of physical memory, the entire system
comes to a crawl for an hour or two.  

I spent some time with top(1) and setting FC_DEBUG=255 in my environment. 
Finally what I discovered is that fc-cache got a pretty long ways into things
using 3-4 Mb of memory and then explodes on a particular font file. 
Interestingly doing

  limit datasize 100e3

(I'm using tcsh) to limit the datasize to 100 Mb didn't cause fc-cache to crash,
it just limited the peak memory usage.  Still, you run along with 3-4 Mb until
you hit a few particular fonts.  So finally I tracked it down to the following
files in /usr/openwin/lib/X11/fonts/misc/:

hanglg16.pcf.Z   hanglm16.pcf.Z   hanglm24.pcf.Z   jiskan16.pcf.Z  
jiskan24.pcf.Z   k14.pcf.Z

Moving those out to some other location causes fc-cache -f to run to completion
without ever going over 3-4 Mb.

So just for kicks, I had a friend try adding these font files to his system
(DragonFly) and he saw the same sort of behaviour.  

I guess there is something that fontconfig doesn't like in the insides of these
files.  On top of that, is there some sort of GC in use that can explain why
limiting the datasize makes the process run to completion instead of crashing
with an out of memory error?  Or perhaps malloc's are failing and not being tested?

To reproduce, just stick the fonts I'm attaching in one of your font directories
and run 'fc-cache -f' and monitor memory usage.

-Dan

Comment 1 Dan McMahill 2006-10-13 10:55:39 UTC

Created attachment 7406 [details]
font files which trigger excessive memory usage

Comment 2 David Halik 2007-05-19 15:43:29 UTC

Hello,

Will there ever be any investigation into this? It is definitely still present in the latest release of 2.4.2. We've been wrestling with this for some time as neither the latest version of Freetype2 or Fontconfig seems to be able to allow parsing of these few files while they are compressed. From what I've seen this bug has been around for quite some time now. If they are uncompressed it reads them fine, but as soon as they are re-compressed fc-cache hangs and sucks up all available memory. I'm posting this at Freetype too since no one seems to be able to agree on whether this is a Freetype issue or Fontconfig issue.

Here is a quick view of what is happening using truss:

munmap(0xFF3A0000, 6623)                        = 0
stat("/usr/openwin/lib/X11/fonts/misc/hanglg16.pcf.Z", 0xFFBFF80C) = 0
open("/usr/openwin/lib/X11/fonts/misc/hanglg16.pcf.Z", O_RDONLY) = 4
fcntl(4, F_SETFD, 0x00000001)                   = 0
fstat(4, 0xFFBFF548)                            = 0
mmap(0x00000000, 312004, PROT_READ, MAP_PRIVATE, 4, 0) = 0xFF020000
close(4)                                        = 0
brk(0x000489A8)                                 = 0
brk(0x000649A8)                                 = 0
brk(0x000649A8)                                 = 0
brk(0x0006C9A8)                                 = 0
brk(0x0006C9A8)                                 = 0
brk(0x000709A8)                                 = 0
brk(0x000709A8)                                 = 0
brk(0x000709A8)                                 = 0
brk(0x000729A8)                                 = 0

Comment 3 David Halik 2007-05-19 15:58:37 UTC

Here is the link to the ticket I opened on Freetype's bug system:

https://savannah.nongnu.org/bugs/index.php?19910

Comment 4 David Halik 2007-05-22 08:46:12 UTC

Looks like it was freetype after all. They've since fixed the bug and I can confirm that their latest CVS does indeed work.

https://savannah.nongnu.org/bugs/index.php?19910

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.