bugGNU Octave - Bugs: bug #45458, Crash of fc-cache on Windows...


bug #45458: Crash of fc-cache on Windows causes slow plots

Submitted by:  None
Submitted on:  Wed 01 Jul 2015 07:55:13 PM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  None
Originator Name:  Fehn, Heinz-Georg Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.0.0
Operating System:  Microsoft Windows

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 17 Aug 2018 08:59:35 PM UTC, comment #40:

I checked in the nuclear option. I used the shell cmd

with the redirection needed to suppress the output.

I'm going to close this report, but it can still be posted to if there are future problems.

Rik <rik5>
Project Administrator
Fri 17 Aug 2018 09:18:02 AM UTC, comment #39:

I am unable to properly reproduce this error with 4.4.0.

When I rename the .cache-7 file to .cache-7.LCK, calling fc-cache.exe with or without "-r" returns "failed"/"failed to write cache".

When I rename the .cache-7 file to .cache-7.NEW, calling fc-cache.exe with or without "-r" returns a success; the .NEW file still exists, a new .cache-7 file is created and subsequent executions of fc-cache.exe return immediately, without recreating the cache.

From my unqualified position it appears that the "nuke-everything"-option (delete the cache dir) is the safer option, since it definitely removes all problematic files. On the other hand, there seems to be no obvious harm in using both options simultaneously. Should fontconfig ever move the cache directory, we can only hope that by then they also handle leftover files...

Philipp Mengs <philwatcher>
Wed 15 Aug 2018 03:42:52 PM UTC, comment #38:

It seems to me that using the -r flag would be better. Can someone test to verify that it does work?

John W. Eaton <jwe>
Project Administrator
Wed 15 Aug 2018 03:06:36 PM UTC, comment #37:

This does not seem to be an Octave bug, rather than an upstream bug in fontconfig. I am tempted to close it. Before doing so, is there any reason not to add

to fc_update.bat? Or would using the '-r' switch be better because then we wouldn't have to worry if the fontconfig directory is moved?

Rik <rik5>
Project Administrator
Tue 13 Mar 2018 02:41:29 PM UTC, comment #36:

Possible Fix: modify fc_update bat to delete the cache folder, then call fc-cache.
Implementation: add "@del /Q /S %LOCALAPPDATA%\fontconfig\cache\" after "@echo off"

Explanation: fc_update.bat calls fc-cache.exe. fc-cache creates and deletes several temporary files, like "$long_hex_string.cache-7.LCK" or "$long_hex_string.cache-7.NEW". If fc-cache is killed before it can delete these temporary files then these files will persist and fc-cache fails the next time it is executed and tries to create these files.

How to test:

  1. Modify a font file, e.g. by renaming it, to force fc-cache to rescan the directories.
  2. run fc_update.bat -> it should now take some time to complete.
  3. cancel the operation as soon as a .NEW file is created in %LOCALAPPDATA%\fontconfig\cache\. There should now be a .NEW file in the directory.
  4. rerun fc_update.bat -> it will now take some time before it fails. The .NEW file remains in the directory.
  5. manually delete all files inside the %LOCALAPPDATA%\fontconfig\cache directory and rerun fc_update.bat -> it should now take some time to complete successfully. There should now be a .cache-7 file inside the directory (and a CACHEFILE.TAG).

Octave must be closed before running fc_update, otherwise the font cache cannot be updated (error: permission denied).

For additional debug info from fc-cache.exe: setting the environment variable FC_DEBUG to 16 prints info about the cache files written (see https://www.freedesktop.org/software/fontconfig/fontconfig-user.html)

This is basically a fontconfig bug and not an octave bug, but the above workaround should fix it. The fix breaks if the fontconfig cache directory changes.
I assume that this bug resurfaces when a font gets added to the system (when other software gets installed) and fc-update is killed at an unfortunate time.

Philipp Mengs <philwatcher>
Tue 13 Mar 2018 10:04:05 AM UTC, comment #35:

I solved this problem for my case by running fc-update as an administrator with the "-r" flag (erase all caches, then rescan). I don't know if the "run as administrator" part fixed it or the "erase all caches". fc-cache.exe now returns quickly and states for all font directories "skipping, existing cache is valid".

Background: It seems that on every initial plot, fc-cache is called. Normally it immediately returns if the cache is valid, and octave plots immediately. If the cache is invalid, it tries to recreate the cache but apparently something fails during the part where the cache is written to disk (my theory), so the font cache remains only in memory (i.e. subsequent plots are fast) but is lost on exiting Octave.

The font cache directory is in C:\users\your_username_here\AppData\Local\fontconfig\cache, and no administrator rights are necessary for fc-cache to recreate this folder when missing, so maybe it is the "-r" flag which solved this.

Philipp Mengs <philwatcher>
Sun 18 Feb 2018 04:26:01 AM UTC, comment #34:

I have observed that renaming C:\Octave\bin\fc-cache.exe to fc-cache-renamed.exe etc.
suppresses the slowing. I want to know if this can be a workaround for this problem.
Does anyone know any side effects of disabling fc-cache.exe?
Thanks in advance.

TJ <otk98>
Mon 22 Jan 2018 04:57:33 PM UTC, comment #33:

I see this under Windows 10 as well, using GNU Octave-4.20. Even for a simple plot, it takes a while to come up.

>> graphics_toolkit

ans = qt
There are discussions around this on stack overflow, and adding this line: graphics_toolkit('gnuplot');
at the end of c:\Octave\Octave-4.2.0\share\octave\site\m\startup\octaverc
Nicely makes it work. Instant plots with that change.

Mon 10 Jul 2017 12:40:34 PM UTC, comment #32:

Bug still exists with octave-4.2.1 on Windows 7 64, 32 and 64 bit, zip file.

Cache is generated once upon every octave start, manually running fc_update does not fix this. Resmon shows that octave-gui.exe is reading every font file (this is a rudimentary progress display since it scans them in alphabetic order). Every plotting after the initial plot works normally (= fast).

Installed version does not suffer from this problem.

Philipp Mengs <philwatcher>
Sun 19 Feb 2017 07:20:26 PM UTC, comment #31:

After a fresh Windows 10 install, and a fresh Octave 4.2.0 install it takes quite some time before the plot in the first plotting window appears after e.g. a plot(x,y) command. It looks like the "Figure 1" window is blocked (or hanging). So the window is there but the content (the plot) is not plotted.

After some time this behavior disappears, and after first plots have been made successfully, visualizing plotting becomes faster, although resizing the window now takes a lot of time. The plot is not redrawn, and one needs to use the circular arrow (redo) button to get the desired result (after some time).
This behavior persists.

Windows 10 & Octave still seem to have difficulties.

Arnoud de Geus <adegeus>
Thu 29 Dec 2016 10:03:42 PM UTC, comment #30:

Are there any other places that this fontcache delay will come up that may or may not be fixed (or at least improved) with this patch? From what I read, win installer will run fc-cache. so if no new fonts are installed the slowdown should be gone. but if a new font is added... how does that trigger re-running the cache-update process? will that be manual or automatic?

For zip-installers, should running the fc-update.bat be a one-time thing? or something to be run everytime octave starts?

Last, the only other delay in windows that seemed similar was seemingly random delayed calls to the pager. It doesn't seem like this would be related, but would someone with procmon be able to verify?

Nicholas Jankowski <nrjank>
Thu 29 Dec 2016 09:44:18 PM UTC, comment #29:

note: Another potential duplicate of this (now hopefully fixed bug) is bug #44471.

Hartmut <hardy>
Thu 01 Dec 2016 07:27:14 PM UTC, comment #28:


John Donoghue <lostbard>
Project Member
Thu 01 Dec 2016 07:16:09 PM UTC, comment #27:

typo in the fc-update.bat:

echo "Updating fc-cache (may take a file) ..."

Nicholas Jankowski <nrjank>
Thu 01 Dec 2016 06:46:41 PM UTC, comment #26:

Pushed http://hg.octave.org/mxe-octave/rev/7f2d5c8c4491

which adds running fc-cache in the installer.

There is also a fc_update.bat script in the base of the files, so should be available to un manually in the zipfile as well

John Donoghue <lostbard>
Project Member
Thu 17 Nov 2016 02:00:10 PM UTC, comment #25:

would also be useful if there was a fix for those using the zip-file to 'install'

Nicholas Jankowski <nrjank>
Mon 17 Oct 2016 07:24:59 PM UTC, comment #24:

Would maybe make more sense at that point to just run fc-cache within the installer.

The other issue is also that as soon as another application installs an additional font, octave will then show the same issue.

John Donoghue <lostbard>
Project Member
Mon 17 Oct 2016 07:09:19 PM UTC, comment #23:

So what about opening a figure as part of the installation?

Avinoam Kalma <avinoam>
Project Member
Mon 17 Oct 2016 12:06:46 PM UTC, comment #22:

For info, trying v2.12.0 doesn't show any speed increase - same 20+ second delay first time a plot is ever generated (when no fontconfig cache was available)

John Donoghue <lostbard>
Project Member
Sun 16 Oct 2016 12:42:31 PM UTC, comment #21:

For windows, could maybe try updating the versuion of fontconfig and see if that helps.

version used is 2.11.1 was released March 2014, latest version looks like 2.12.0, released June 2016.

John Donoghue <lostbard>
Project Member
Sun 16 Oct 2016 04:45:04 AM UTC, comment #20:

Is it possible to plot a test figure during Octave installation, so the delay in the building of fontconfig directory will be part of the installation?

Avinoam Kalma <avinoam>
Project Member
Sat 15 Oct 2016 07:09:51 PM UTC, comment #19:

Bug #49300 reports the same delay on the first plot on MacOS 10.12 (Sierra). On Stackoverflow there are reports that this can take up to 3min. I think the solution here would be really a popup window with a progressbar to inform the user.

Andreas Weber <andy1978>
Project Member
Wed 16 Mar 2016 05:19:47 PM UTC, comment #18:

I could get the 30+ sec delay on my windows 7 machine if I delete the fontcache from %LOCALAPPDATA%\fontconfig

After it generated it, I didn't have any delays, not any issues with later runs of octave plotting

Looking around, on mine, no fontconfig cache was added to %TEMP%, so no potential issues on reboots.

John Donoghue <lostbard>
Project Member
Wed 27 Jan 2016 04:22:30 PM UTC, comment #17:

It sounds so. In my windows 7 I had slow executing only the very first time I launched octave and plotted.
After your suggestion, I deleted the font cache, that is in
and not %TEMP%
and back again it was slow.

Andrea Monti-Guarnieri <amuser>
Wed 13 Jan 2016 09:23:03 PM UTC, comment #16:

Is it possible that the fontconfig chache is generated in %TEMP%\fontconfig\cache and some users have settings/tools which clear the %TEMP% folder on startup?

This could explain why some users see the delay only once if the a plot is shown, some others between restarts and others between logoff/login.

See also http://sourceforge.net/p/mplayerwin/bugs/1/
perhaps we can move the fontconfig cache to the Octave install directory

Andreas Weber <andy1978>
Project Member
Tue 24 Nov 2015 09:02:59 PM UTC, comment #15:

@Julien: your comment makes me think that cache files are stored in a "volatile" dir such as /tmp on linux, erased after closing a user session. Where are cache files stored on windows? What is the value of fontconfig configure options "--localstatedir" (or better "--with-cache-dir=DIR") in mxe?

Also is fc-cache installed along with mxe-octave? If so can you try to run it prior to your first plot in a windows session? Something like:

Pantxo Diribarne <pantxo>
Project Member
Tue 24 Nov 2015 04:53:16 PM UTC, comment #14:

This fontconfig bug report may be relevant: https://bugs.freedesktop.org/show_bug.cgi?id=64766

It is suggested in the bug log that perhaps fontconfig is not well suited for non-GNU/Linux systems (no idea of the authority or veracity of that claim).

Mike Miller <mtmiller>
Project Administrator
Tue 24 Nov 2015 04:30:14 PM UTC, comment #13:

Cool, at least now we have a suspect. Thank you Andrea for investigating this.

Assuming that it is indeed fontconfig initializing its font files cache that is the cause of the problem, I think that:

a) Doing it at startup with an explicit wait message, as suggested by Pantxo, would of course be much better than having Octave frozen for 40s, without explanation, when the first figure is created.

b) But even this would be slightly annoying, I think. One thing that I love about Octave, is that is starts quickly. Do I really have to wait 40 seconds when I start Octave GUI for the first time in a given Windows session? I would prefer not to...

Wouldn't it be possible to scan for font files when Octave is installed, and then provide a command somewhere in a menu to rescan if needed?

Julien Bect <jbect>
Wed 11 Nov 2015 10:47:35 AM UTC, comment #12:

So it looks like the freeze is due to fontconfig initializing its font files cache. What about calling "FcInit ()" (currently in "txt-eng-ft.cc (ft_manager::ft_manager)") at startup and displaying a splash screen as proposed in bug #41088?
AFAIR this is what GIMP does on mac, clearly stating that it is loading font files.

Pantxo Diribarne <pantxo>
Project Member
Wed 04 Nov 2015 03:17:30 PM UTC, comment #11:

One more piece of information. Same problem, win 7 64 bit. First time plotting hangs for a while, later plots are OK.
I tried debuggining with procmon, and I fìdiscover that -while hanging- it is actually reading (or scanning) all the fonts file in windows/font folder, in alphabetic oder from the first to the last: they are > 400 files there.

Andrea Monti-Guarnieri <amuser>
Fri 25 Sep 2015 02:50:37 PM UTC, comment #10:

One more piece of information: during the 40 second delay that I observe, the memory occupied by octave-gui.exe goes up from 32Mo to roughly 70Mo, then fluctuates and finally stabilizes around 50Mo (>> 32 Mo).

Julien Bect <jbect>
Fri 25 Sep 2015 02:47:56 PM UTC, comment #9:

@Philip (answering message on maintainers list)


1) Based on my experiments, the problem is unrelated with the creation of qt-settings (see Comment #5).

2) The problem appears both with the CLI and with the GUI. The delay that I observe is the same in both cases (approx. 40s) and it is also the same with qt/fltk/gnuplot.

Julien Bect <jbect>
Fri 25 Sep 2015 02:41:47 PM UTC, comment #8:

@Andreas (comment #7):

1) I am surprised that your colleagues sees the problem disappear after a reboot. In my case, a simple close/repon of my session is enough to make it re-appear. Are you sure about that?

2) The process that uses CPU time is octave-gui.exe, but it only takes 13% approximately.

Julien Bect <jbect>
Fri 25 Sep 2015 12:16:03 PM UTC, comment #7:

A colleague tried GNU Octave 4.0 MXE build on Win7 64bit. The first plot was very slow (30s for plot (1:10)) and afterwards fast as expected even after deleting .config/octave or reboot.

Do you see which process uses CPU in task-manager?

Andreas Weber <andy1978>
Project Member
Thu 24 Sep 2015 09:59:58 AM UTC, comment #6:

One more piece of information: the Win7/64 machine where the problem occurs has a roaming user profile, while the Win7/32 has not. Perhaps is it relevant...

@Heinz-Georg Fehn: do you have a romaing profile as well?

Julien Bect <jbect>
Thu 24 Sep 2015 09:47:00 AM UTC, comment #5:

Some more information regarding this problem:

1) I also have a Win7/32bit machine, but I don't see the problem there. I have no idea if this 32bits/64bits difference is relevant...

2) I have true deleting .config/octave/qt-settings as suggested by Dan. When I close and re-open Octave, qt-settings is created, but the problem does not reappear. It only reappaears if I close my Windows session and log in again.

I really don't have a clue about what's going on.

Julien Bect <jbect>
Mon 21 Sep 2015 03:14:54 PM UTC, comment #4:

I just observed exactly the same problem (Win7/64, Octave 4.0.0).

The first plotting command taks a very long time to succeed. But then, successive plotting commands are fast as expected.

It remains fast if I close Octave and restart, within the same Windows sessions.

The problem comes back if I close my Windows session and open a new one.

I will try to see what happens if I deleter some settings files...

Julien Bect <jbect>
Sat 11 Jul 2015 05:19:22 PM UTC, comment #3:

Strange one, and unfortunately difficult to debug without consistency. Could you try deleting or renaming your settings file and relaunch to see if the delay occurs again? The file on Linux is located in


Dan Sebald <sebald>
Tue 07 Jul 2015 08:55:40 AM UTC, comment #2:

Thank you for your answer, but the problem occurs using 'qt'.
The main problem was the response time for generating the first plot. After installing qctave again and waiting for 1 min calling plot(1:10) the figure and the content in it was correct.

After that, the response time for plots are okay. It looks that this problem occurs only in initialization the features for 'qt'.
Best regards

Heinz-Georg Fehn

Tue 07 Jul 2015 08:06:16 AM UTC, comment #1:

When changing to gnuplot, you might have to create a new figure.

Does gnuplot work for plotting then?

Dan Sebald <sebald>
Wed 01 Jul 2015 07:55:13 PM UTC, original submission:

using octave 4.0.0-0 it run including plot. After run matlab Version 2014b 64 bit once on Windows 7 octave could not motivated to go on with the plot command plot(1:10). It freezes. Other elements which does not use figures or plot work well. I tryed to change graphics to gnuplot, but nothing is going on.

Deinstalling and installing octave again leads to the same Problem.

What is the reason and do you need any more information please let me know it.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by otk98 (Posted a comment)
  • -email is unavailable- added by philwatcher (Posted a comment)
  • -email is unavailable- added by amro_octave
  • -email is unavailable- added by adegeus (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by amuser (Posted a comment)
  • -email is unavailable- added by jbect
  • -email is unavailable- added by jbect
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by jbect (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 19 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-17 rik5 Item GroupNone => Performance
        StatusNeed Info => Fixed
        Open/ClosedOpen => Closed
    2018-08-15 rik5 StatusNone => Need Info
        SummaryPlot does not work and freeze => Crash of fc-cache on Windows causes slow plots
    2017-10-08 mtmiller Dependencies- => bugs #50354 is dependent
    2017-06-05 amro_octave Carbon-Copy- => Added amro_octave
    2016-11-01 andy1978 Dependencies- => bugs #49457 is dependent
    2016-10-10 pantxo Dependencies- => bugs #49300 is dependent
    2016-09-20 andy1978 Dependencies- => bugs #49127 is dependent
    2016-05-10 mtmiller Dependencies- => bugs #47889 is dependent
    2016-03-21 mtmiller Dependencies- => bugs #45991 is dependent
    2016-03-21 mtmiller Dependencies- => bugs #46263 is dependent
    2016-03-21 mtmiller Dependencies- => bugs #47463 is dependent
    2016-02-21 mtmiller Dependencies- => bugs #46046 is dependent
    2016-02-21 mtmiller Dependencies- => bugs #46090 is dependent
    2016-02-21 mtmiller Dependencies- => bugs #47182 is dependent
    2015-09-25 jbect Carbon-Copy- => Added -email is unavailable-
    2015-09-25 jbect Carbon-Copy- => Added -email is unavailable-

    Back to the top

    Powered by Savane 3.4