I can't provide details as I am not a software developer, but: I have tested installation on Debian Sid, on 7 machines, and two of them failed to install fontconfig. The interesting thing is that two workstations have exactly the same packages installed and yet one of them did not work. All three machines have the KDE 3.0.5a installed. Two machines have the same ASUS mother board and 500MB of DDR RAM.The difference is the speed of the CPU's and the video cards.One has GeForce2 and the other GeForce4. The one with GeForce4 failed the installation. But both, failed previous version of fontconfig. The machine that failed the installation, just sat at the creation of the font-cache. I had to abort it's installation. Now the interesting part, yesterday I tried to install Fontconfig on my notebook PII-233MHz, 160 MBytes, KDE3.0.5a, and it failed three attempts. Everytime it run out of memory and the installer began to shut some of the running processes. It failed the same way when I restarted my notebook without the KDE running. Every time I got an error message telling me to look at the .log file, which was empty. The package was installed as far as the dselect was concerned, but KDE login screen never came up, it just sat at the mouse ponter and the hour glass. Machine was still running, because I could switch to other consoles to check memory usage with the free. Removal of the font fontconfig fixed the problem.I noticed that font config is a real hog on the memory, as the notebook had no memory left with fontconfig sort of installed and hanging at the KDE login prompt. To the contrast machine less than 50 MBytes without the fontconfig while the KDE was running. I transferred the system image from one machine to the other, and the workstations show 500MBytes used, with only 250MBytes available, while the fontconfig is installed. Regards, Nick
I've had several reports of large memory usage when launching fontconfig based apps when fc-cache hasn't been run. Can you try (as root) 'fc-cache -f' and then attempt to run an app and see if this is the same problem?
As Keith mentioned in private mail it is the problem with some versions of FreeType, so I provide the version I use: 2.1.3. I debugged the stuff and figured out that FT_New_Face() function in FreeType library (really it's the problem with open_face() function there) sometimes allocates about 40k RAM even if it didn't find the font needed. It contains the ugly gotos ( as fontconfig does also ;) ) for error handling. Something like if( FT_ALLOC( face, ... ) ) goto Fail; if( FT_New( internal ) ) goto Fail; ... face->internal = internal; ... if( error ) goto Fail; ... Fail: if( error ) { clazz->done_face( face ); FT_FREE( face->internal ); FT_FREE( face ); } return error; Bruteforce hacking ( like if( internal ) FT_FREE( internal ); etc ) headed me to segmentation fault. So I should hack it a little bit more. Anyway it's not fontconfig problem & it can't be fixed from inside the library (I tried to enforce FT_Done_Face() call from the fontconfig library but it didn't free the memory). Regards, Dima
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.