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.
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.
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).
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.
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.
The previous fix in fbc05949ef 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
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
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
'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.
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>
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>
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.
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/
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
Akira TAGOH
Ben Wagner
Alex Richardson
Tim-Philipp Müller
Mathieu Duponchelle
Keith Packard
Robert Yang
Matthieu Herrb
Tom Anderson
Alexander Larsson
Chris Lamb