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
Created attachment 7406 [details] font files which trigger excessive memory usage
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
Here is the link to the ticket I opened on Freetype's bug system: https://savannah.nongnu.org/bugs/index.php?19910
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.