New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metrics window infinite recursion(?) and segfault with complicated GSUB feature #1138

mskala opened this Issue Jan 26, 2014 · 2 comments


None yet
2 participants

mskala commented Jan 26, 2014

The metrics window seems to go nuts when processing a complicated GSUB feature. I'm not sure exactly what the circumstances are that trigger this, and my example isn't a very clean one, but here's a crash that's reliably reproducible on my 64-bit Linux with the current Git master version:

  1. Download, and open in the GUI, the font from
  2. Multiple-select, in this order using shift-click, these glyphs: uni1100 (looks like ㄱ , though that is actually U+3131); uniAC00 (looks like 가); uni11A8 (looks like ㄱ , though that is actually U+3131 again).
  3. Open a metrics window. The three characters should appear as a single glyph, uniAE4D, which looks like 깍, as a result of a series of lookup substitutions in the OpenType ccmp and liga GSUB features.
  4. Change the selected set of OpenType features in the scroll box at the left of the metrics window. It doesn't seem to matter exactly what change is made, but clicking on "afrc" to select it and deselect all the others works.
  5. What should happen: the display changes according to the new choice of features. What happens instead: the display changes, but then FontForge's CPU usage goes to maximum, further GUI updates stop happening, and after a few seconds there's a segmentation fault.

I tried to collect a stack backtrace, but gave up after 30000 stack frames. It looks like there is some chunk of GUI code going through infinite recursion involving creating a text box or something. Eventually, after a surprisingly long time under the circumstances, it can't expand the stack any further and dies.

The characters in my example, U+1100 U+AC00 U+11A8, are a bit special, which is why I couldn't type some of them directly into this report. Unicode provides more than one way of writing Korean. The most popular way of doing it is with single code points that represent entire syllables; U+AC00 is "GA" and U+AE4D is "GGAG", both of which are allowed as syllables in Korean. However, there are also code points for individual letters and various combinations of letters, so that the same "GGAG" syllable could be spelled U+1101 U+1161 U+1148 ("GG/A/G"), and it's possible to have a lengthy discussion of to what extent it is or isn't okay to mix the different ways of forming syllables (for instance, "GG/A/G" is preferred over "G/G/A/G", and it's questionable whether the latter should be allowed at all). We are having that discussion now on the HarfBuzz mailing list, which is how I discovered this bug in FontForge. The sequence U+1100 U+AC00 U+1148 ("G/GA/G") is pushing the boundaries of what Unicode will allow, but the font in my example contains unfinished experimental substitution tables intended to convert that sequence into a single glyph equivalent to U+AE4D ("GGAG"), by means of several cascading lookups in the ccmp and liga features. And FontForge breaks on those substitutions.


This comment has been minimized.


frank-trampe commented May 26, 2014

This ought to be fixed in commit 00def29 via pull request #1371. I'll wait for verification from @mskala before closing.


This comment has been minimized.


mskala commented May 26, 2014

As on the other ticket, cherry-picking commit 00def29 seems to fix the problem. Thank you.

@mskala mskala closed this May 26, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment