summaryrefslogtreecommitdiff
path: root/src/fccache.c
Commit message (Collapse)AuthorAgeFilesLines
* Report more detailed logs instead of assertion.Akira TAGOH2023-01-251-10/+7
| | | | | | | | Getting backtraces against this assertion isn't useful at all. Fontconfig isn't capable to report who really have a reference of caches though, this report may be better than assertion. So we can try analysis tools then. And report it only when running with FC_DEBUG=16.
* Free local FcCache lock on contentionBen Wagner2021-09-061-0/+1
| | | | | | | | | | If two threads attempt to create the FcCache lock in lock_cache at the same time, both threads may create and initialize a local FcMutex. One thread will atomically make cache_lock point to its FcMutex. The other thread currently calls FcMutexFinish on the local lock, but does not free it. Change this behavior to free the unused lock. Found with test/test-pthread on an LeakSanitizer enabled build.
* Fix a memory leak when trying to open a non-existing fileAkira TAGOH2021-08-251-5/+7
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1914716
* Add support for C11 stdatomic atomicsAlex Richardson2021-07-201-1/+1
| | | | | | | | This fixes deprecation warnings when building for macOS >= 10.12 systems. Additionally, using stdatomic.h (or the more modern __atomic_ builtins) is required when targeting CHERI-enabled architectures such as CHERI-RISC-V or Arm's Morello since the compiler rejects __sync_* atomic for pointer types (they only work with integers).
* Fix fc_atomic_ptr_get and use.Ben Wagner2020-11-021-1/+3
| | | | | | | | | | | Before this change building with ThreadSanitizer and running test/test-pthread generated a large number of threading issues. These mostly stemmed from fc_atomic_ptr_get not doing an atomic load and using "acquire load" instead of "load acquire". After making these changes it was still necessary to use fc_atomic_ptr_get where it was needed. This also documents the current memory barrier requirements for the atomic primitives.
* Make more clearer the license termsAkira TAGOH2020-09-031-255/+1
| | | | | | COPYING is missing non-expat license terms for some files and some files is also missing license terms. This is changes to makes it clearer and update. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/219
* Fix build issues regarding formatter for Win32Akira TAGOH2020-08-061-3/+3
| | | | Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/248
* Guard dirent.h includesTim-Philipp Müller2020-07-271-0/+2
| | | | Might not be available on Windows.
* Fix empty XDG_CACHE_HOME BehaviorAkira TAGOH2020-07-141-0/+2
| | | | | | Use the default $HOME/.cache one for empty XDG_CACHE_HOME. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/243
* Fix build on Windows some moreTim-Philipp Müller2020-07-011-0/+2
|
* Some build fixes to support compilation with MSVC on WindowsMathieu Duponchelle2020-07-011-1/+5
|
* Fix cache conflicts on OSTree based systemAkira TAGOH2020-05-121-3/+25
| | | | | | | | | | | | mtime isn't reliable to detect updates of fonts on OSTree based system since they reset mtime to 0 for system files. Due to this, there are the situation likely to happen where mtime is newer but content is older. Fortunately, OSTree based system requires reboot to deploy changes. so we can assume we won't see any changes on system fonts. so system caches are always up-to-date. we can ignore meta data for system fonts in user caches.
* Fix assertion in FcCacheFini() againAkira TAGOH2020-03-231-2/+15
| | | | | | | | | | | | | | The previous fix in fbc05949ef52c8a8d69233eed77f6636dffec280 was wrong. reverting. When reading older caches, FcDirCacheMapHelper() returns FcFalse and it became the return value from FcDirCacheProcess() too, which is wrong. Actually one of calls for FcDirCacheMapHelper() should be successfully finished and closure should have a valid pointer for cache. Due to this, the proper finalization process wasn't running against cache in closure. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/227
* Fix assertion in FcFini()Akira TAGOH2020-02-261-4/+5
| | | | | | | | Due to the unproper initialization of `latest_mtime', the duplicate caches was still in fcCacheChains with no references. which means no one frees them. thus, the memory leak was happened. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/227
* Fix potential race condition in FcConfigSetCurrent and FcConfigReferenceAkira TAGOH2019-11-061-0/+2
|
* Use FcConfigReference/Destroy appropriately instead of FcConfigGetCurrentAkira TAGOH2019-11-011-15/+58
| | | | | | This may improves to be MT-safe. Reported at https://bugs.chromium.org/p/chromium/issues/detail?id=1004254
* Fix a memory leak caused by the previous commitAkira TAGOH2019-10-311-0/+4
|
* Read latest cache in pathsAkira TAGOH2019-10-281-6/+30
| | | | | | | | | | | | | Right now fontconfig uses a cache found first in a path and cachedirs are the order of the system-wide path and then the user path. this is due to avoid writing caches into the user path when running as root. However, changing caches by certain config only, e.g. using <match target="scan"> may not take effect by this behavior, because it may be stored into the user path. Thus, needing to find the latest cache out from paths. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/182
* Fix the fail on fc-cacheAkira TAGOH2019-07-231-4/+13
| | | | | | Fallback code to UUID-based cache name was broken. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/169
* Fix endianness on generating MD5 cache nameAkira TAGOH2019-06-101-1/+1
|
* No need to remap for uuid basedAkira TAGOH2019-04-041-19/+17
|
* Fallback uuid-based name to read a cache if no MD5-based cache availableAkira TAGOH2019-04-041-2/+89
|
* Oops, Terminate stringAkira TAGOH2019-04-031-0/+1
|
* Add some debugging outputAkira TAGOH2019-04-031-4/+14
|
* Add salt attribute to dir and remap-dir elementsAkira TAGOH2019-04-031-1/+14
| | | | | | | | | | | 'salt' attribute affects a cache filename to generate different name from directory name. This is useful when sharing caches with host on sandbox and/or give a filename differently: <dir salt="randomdata">/usr/share/fonts</dir> <remap-dir as-path="/usr/share/fonts" salt="salt for /usr/share/fonts on host">/run/host/fonts</remap-dir> Applications can read caches as-is for fonts on /run/host/fonts where is mounted from host. and write a cache for their own fonts on /usr/share/fonts with different name.
* Drop a line to include uuid.hAkira TAGOH2019-04-031-2/+0
|
* Replace UUID file mechanism with per-directory 'map' attribute [v2]Keith Packard2019-04-031-196/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The UUID files would be placed in each font directory to provide the unique cache name, independent of path, for that directory. The UUID files are undesireable for a couple of reasons: 1) They must be placed in the font directories to be useful. This requires modifying the font directories themselves, introducing potential visible timestamp changes when running multiple applications, and makes the cache processing inconsistent between applications with permission to write to the font directories and applications without such permission. 2) The UUID contents were generated randomly, which makes the font cache not reproducible across multiple runs. One proposed fix for 2) is to make the UUID dependent on the font directory path, but once we do that, we can simply use the font directory path itself as the key as the original MD5-based font cache naming mechanism did. The goal of the UUID file mechanism was to fix startup time of flatpaks; as the font path names inside the flatpak did not match the font path names in the base system, the font cache would need to be reconstructed the first time the flatpak was launched. The new mechanism for doing this is to allow each '<dir>' element in the configuration include a 'map' attribute. When looking for a cache file for a particular directory, if the directory name starts with the contents of the <dir> element, that portion of the name will be replaced with the value of the 'map' attribute. Outside of the flatpak, nothing need change -- fontconfig will build cache files using real directory names. Inside the flatpak, the custom fonts.conf file will now include mappings such as this: <dir map="/usr/share/fonts">/run/host/fonts</dir> When scanning the directory /run/host/fonts/ttf, fontconfig will use the name /usr/share/fonts/ttf as the source for building the cache file name. The existing FC_FILE replacement code used for the UUID-based implementation continues to correctly adapt font path names seen by applications. v2: Leave FcDirCacheCreateUUID stub around to avoid removing public API function. Document 'map' attribute of <dir> element in fontconfig-user.sgml Suggested-by: Akira TAGOH <akira@tagoh.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* Reset errno to do error handling properlyAkira TAGOH2019-04-031-0/+1
| | | | | | This fixes the weird behavior when running with SOURCE_DATE_EPOCH=0: Fontconfig: SOURCE_DATE_EPOCH: strtoull: No such file or directory: 0
* Ifdef'ed unnecessary code for Win32Akira TAGOH2019-03-221-3/+5
| | | | Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/147
* src/fccache.c: Fix define for HAVE_POSIX_FADVISERobert Yang2019-01-251-1/+1
| | | | | | | | | Otherwise, there would be build errors in the following 2 cases: * define HAVE_POSIX_FADVISE Or: * undef HAVE_POSIX_FADVISE Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
* Fix a dereference of a null pointerAkira TAGOH2018-11-301-7/+10
| | | | | When exiting from for loop by not satisfying the condition of `(s = next[i])` at FcCacheRemoveUnlocked() referring s->alloated will be invalid.
* Do not try updating mtime when unlink was failedAkira TAGOH2018-10-051-10/+13
|
* Do not update mtime when removing .uuid fileAkira TAGOH2018-10-051-5/+27
| | | | | | This avoids a situation triggers updating caches on a directory where .uuid file was removed. Resolves: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/107
* Fix array access in a null pointer dereferenceAkira TAGOH2018-07-191-1/+1
| | | | | | | | | | FcFontSetFont() accesses fs->fonts in that macro though, there was no error checks if it is null or not. As a result, there was a code path that it could be a null. Even though this is unlikely to see in usual use, it might be intentionally created in a cache. So if fs->fonts is a null, we should consider a cache is invalid.
* Fix unterminated string issueAkira TAGOH2018-07-191-1/+4
|
* Fix memory leakAkira TAGOH2018-07-191-1/+1
|
* Fix the leak of file handleAkira TAGOH2018-07-191-0/+1
|
* FcCacheFindByStat(): fix checking of nanoseconds field.Matthieu Herrb2018-07-101-1/+1
|
* Fix heap use-after-freeTom Anderson2018-06-131-1/+1
|
* Remove .uuid when no font files exists on a directoryAkira TAGOH2018-06-111-0/+22
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=106632
* Cache: Remove alias_tableAlexander Larsson2018-05-251-12/+3
| | | | | | There is really no need for this anymore https://bugs.freedesktop.org/show_bug.cgi?id=106618
* Add FcCacheAllocate() helperAlexander Larsson2018-05-251-0/+36
| | | | | | | This lets you allocate a chunk of memory that will be freed when the cache is freed. https://bugs.freedesktop.org/show_bug.cgi?id=106618
* Ensure cache checksums are deterministicChris Lamb2018-05-161-6/+53
| | | | | | | | | | | | | | | | | | | | | | | | Whilst working on the Reproducible Builds[0] effort, we noticed that fontconfig generates unreproducible cache files. This is due to fc-cache uses the modification timestamps of each directory in the "checksum" and "checksum_nano" members of the _FcCache struct. This is so that it can identify which cache files are valid and/or require regeneration. This patch changes the behaviour of the checksum calculations to prefer the value of the SOURCE_DATE_EPOCH[1] environment variable over the directory's own mtime. This variable can then be exported by build systems to ensure reproducible output. If SOURCE_DATE_EPOCH is not set or is newer than the mtime of the directory, the existing behaviour is unchanged. This work was sponsored by Tails[2]. [0] https://reproducible-builds.org/ [1] https://reproducible-builds.org/specs/source-date-epoch/ [2] https://tails.boum.org/
* Bug 106459 - fc-cache doesn't use -y option for .uuid filesAkira TAGOH2018-05-131-11/+37
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=106459
* Disable uuid related code on Win32Akira TAGOH2017-12-181-1/+18
|
* Do not update mtime with creating .uuidAkira TAGOH2017-12-181-0/+26
|
* Replace uuid in the table properly when -rAkira TAGOH2017-12-181-1/+6
|
* Fix memory leakAkira TAGOH2017-11-201-3/+4
|
* abstract hash table functionsAkira TAGOH2017-11-201-213/+28
|
* Destroy the alias and UUID tables when all of caches is unloadedAkira TAGOH2017-11-201-36/+27
| | | | | | | | | When a cache contains no fonts, it will be unloaded immediately. Previously the certain alias and UUID entries will be purged at that time though, this doesn't work when the targeted directory has sub-directories. To avoid the unnecessary cache creation with the md5-based naming, try to keep them as far as possible. Although this way seems not perfectly working if the first directory to look up is like that
View Lorry Controller Status