Bug 39278 - make usage of mmap optional
Summary: make usage of mmap optional
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2_1
Hardware: Other All
: medium major
Assignee: Akira TAGOH
QA Contact: Behdad Esfahbod
: 27041 34621 (view as bug list)
Depends on:
Reported: 2011-07-16 06:42 UTC by Oswald Buddenhagen
Modified: 2012-04-25 18:47 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Description Oswald Buddenhagen 2011-07-16 06:42:17 UTC
ref https://bugs.kde.org/show_bug.cgi?id=272870

fontconfig's usage of mmap may lead to sigbus when the mapped file disappears, e.g. due to an NFS failure. this is fatal if the crashed application happens to be the screensaver.
consequently, it should be possible to disable mmap use alltogether.
Comment 1 Behdad Esfahbod 2011-07-18 10:54:37 UTC
This is really nasty...

What kind of optional do you think would fix the problem?  Who decides whether to use mmap() or read()?
Comment 2 Oswald Buddenhagen 2011-07-18 13:41:14 UTC
i've been wondering, too.
the quick hack would be just having an environment variable to control it and the screensaver would directly set it.
the right solution would be some proper api which would be used by the next higher level, in this case qt. that one in turn would have to expose an api to disable all kinds of mmaps.
Comment 3 Behdad Esfahbod 2011-07-18 14:01:32 UTC
Or simply do that for NFS cachedirs?
Comment 4 Oswald Buddenhagen 2011-07-19 00:03:04 UTC
that may be an option, though keeping the list of nfs-(un)save FSs current is a bit challenging. it's unfortunate that there is no standardized interface to query "mmap-safety" of particular files afaik ...
Comment 5 Alec Warner 2011-08-03 11:21:26 UTC
Quick question.

We are hitting this problem often; will fontconfig still work if I just drop the <cachedir>~/.fontconfig</cachedir> part from fontconfig (on our local installs.)

Will this just result in a slowdown (uncached font information?)

My concern is that this will break per-user ~/.fonts.conf and we have a lot of those; breaking them would be bad.

I have another hack where most homedirs have a .cache symlink that points to local disk; but I want to avoid relying on it.

Comment 6 Behdad Esfahbod 2011-08-03 11:28:47 UTC
Avoiding the cache is not good.   Redirect them to /tmp or something, yeah.
Comment 7 Akira TAGOH 2012-04-10 07:47:50 UTC
*** Bug 34621 has been marked as a duplicate of this bug. ***
Comment 8 Behdad Esfahbod 2012-04-10 07:57:51 UTC
Note that just fixing fontconfig is not enough.  Font files are mmap()ed by FreeType, and used by applications.  Many many other cache files are also mmap()ed.
Comment 9 Akira TAGOH 2012-04-11 02:33:23 UTC
We may want to have something like FcStatFS() that calls statfs() on Linux and similar for other platforms. we can check if the cachedir is mounted on nfs, and disable mmap if it is.
Comment 10 Akira TAGOH 2012-04-11 03:55:50 UTC
the proposed fix:

I'm sure we need to polish this patch for other platforms and filesystems might causes the same problem perhaps.
Comment 11 Akira TAGOH 2012-04-11 04:57:17 UTC
updated with FreeBSD and NetBSD support.
Comment 12 Akira TAGOH 2012-04-11 18:42:12 UTC
*** Bug 27041 has been marked as a duplicate of this bug. ***
Comment 13 Akira TAGOH 2012-04-13 00:51:42 UTC
updated a bit. just wonder how many platforms it do support so far.
Comment 14 Akira TAGOH 2012-04-16 03:23:34 UTC
tested on Solaris 11 too. it seems working.
Comment 15 Akira TAGOH 2012-04-18 20:05:02 UTC
Updated with adding FONTCONFIG_USE_MMAP envvar. setting true to this envvar behaves similarly without this patch. I mean it uses mmap(2) without statfs and so on if mmap(2) is available.
Comment 16 Akira TAGOH 2012-04-25 01:30:13 UTC
committed into git with 7d65f9f5
Comment 17 Behdad Esfahbod 2012-04-25 10:08:17 UTC
In the interest of simplicity, I would remove the env var.  Unless there's a real usecase to that.
Comment 18 Akira TAGOH 2012-04-25 18:47:51 UTC
(In reply to comment #17)
> In the interest of simplicity, I would remove the env var.  Unless there's a
> real usecase to that.

There are some reasons. one is to provide a workaround for any other problematic filesystems that may causes similar issues. it can be patched out later though. one is to bypass a syscall when surely no need to check if it's on nfs or not.

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.