libfontconfig causes SIGBUS due to mmap and NFS interaction.

Bug #820134 reported by Alec Warner on 2011-08-03
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released
fontconfig (Ubuntu)

Bug Description


man mmap specifies the occasions when sigbus is sent:

       SIGBUS Attempted access to a portion of the buffer that does not correspond to the file (for
              example, beyond the end of the file, including the case where another process has trun‐
              cated the file).

If users are using homedirectories on NFS; a simple NFS failure may cause a file size to change.

Users originally reported this problem running eclipse and seeing 3-4 crashes per day.

I believe the workaround we are proposing is to modify /etc/fonts/fonts.conf

<!-- Font cache directory list -->

and just remove the ~/.fontconfig section (possibly replacing it with something on local disk if that is supported.)

antarus@goats2 /etc/fonts $ lsb_release -rd
Description: Ubuntu 10.04.2 LTS
Release: 10.04

antarus@goats2 /etc/fonts $ apt-cache policy fontconfig
  Installed: 2.8.0-2ubuntu1
  Candidate: 2.8.0-2ubuntu1

I expect fontconfig to handle mmap's properly. Upstream is aware of the problem but I don't see a fix yet.
The application SIGBUS's


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.

This is really nasty...

What kind of optional do you think would fix the problem? Who decides whether to use mmap() or read()?

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.

Or simply do that for NFS cachedirs?

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 ...

Changed in fontconfig:
importance: Unknown → High
status: Unknown → Confirmed

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.


Avoiding the cache is not good. Redirect them to /tmp or something, yeah.

*** Bug 34621 has been marked as a duplicate of this bug. ***

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.

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.

the proposed fix:

I'm sure we need to polish this patch for other platforms and filesystems might causes the same problem perhaps.

updated with FreeBSD and NetBSD support.

*** Bug 27041 has been marked as a duplicate of this bug. ***

updated a bit. just wonder how many platforms it do support so far.

tested on Solaris 11 too. it seems working.

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.

committed into git with 7d65f9f5

In the interest of simplicity, I would remove the env var. Unless there's a real usecase to that.

(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.

Changed in fontconfig:
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in fontconfig (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.