Summary: | fc-cache -fr throws an unexpected error | ||
---|---|---|---|
Product: | fontconfig | Reporter: | abmelden22 |
Component: | fc-cache | Assignee: | Akira TAGOH <akira> |
Status: | RESOLVED FIXED | QA Contact: | Behdad Esfahbod <freedesktop> |
Severity: | normal | ||
Priority: | medium | CC: | akira, fontconfig-bugs |
Version: | 2.11 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Log with FC_DEBUG=128
Log of my second encounter of this behaviour |
Description
abmelden22
2014-04-09 20:17:08 UTC
what does it say if you run fc-cache with FC_DEBUG=128? Created attachment 97163 [details]
Log with FC_DEBUG=128
Thanks. Fixed in git with one liner patch. http://cgit.freedesktop.org/fontconfig/commit/?id=f44157c809d280e2a0ce87fb078fc4b278d24a67 Created attachment 101015 [details]
Log of my second encounter of this behaviour
The bug seems to have re-appeared in version 2.11.1 (see new attachment). I was testing fc-cache on a 32-bit system this time, in case that matters. (In reply to comment #5) > The bug seems to have re-appeared in version 2.11.1 (see new attachment). The above fix isn't yet in any released one. please try again with git's or backport a patch. It seems that the bug can be workarounded with: 1/ fc-cache -vrf => clean cache (and then fail on regeneration) and then then: 2/ fc-cache -vf" => no --really-force the second time, so the parameter is correct in scanDirs that time. Hope it helps other. |
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.