abrt version: 1.1.13
Attached file: backtrace
cmdline: fontforge /home/ian/MikmaqReserve.sfd
reason: Process /usr/bin/fontforge was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Goddard)
In this case the key pressed was the space bar; however, this crash happens when other keys are pressed (I've tried Enter, direction arrows, and some letters).
Using the mouse does not cause a similar crash.
This did not happen in Fedora 11, in which I regularly used the keyboard to edit glyphs in FontForge. But ever since the upgrade to Fedora 13, this problem has consistently appeared whenever any key is pressed.
How to reproduce
1. Load a font with FontForge (no problem).
2. Double-click with mouse on one font glyph, to open editor window for that glyph (no problem).
3. Press any key on the keyboard while glyph editing window active (application automatically crashes).
Created an attachment (id=444329)
I am struggling to reproduce this, despite the full backtrace and your good explanation. I can't get this to go wrong with this version, the version based on 20100501 from fc14, or current upstream.
1. Had you selected any points on the current glyph before pressing another key on the keyboard, or selected a particular tool? I ask because, in the absence of any selected points, I don't know why you'd be pressing Enter or arrow keys. Pressing normal alphanumerics should have the effect of opening tabs for other glyphs in the current editor window, and that works as expected for me.
2. Does this happen only on one particular font, and is there anything odd about the coverage of that font?
3. It may help to reproduce the problem if you can supply your personal prefs for FontForge (~/.FontForge/prefs), which you may wish to censor by removing the "Recent" lines from the bottom.
4. If the problem appears to be with a particular font, perhaps you could supply that too, either here or to me privately.
Created attachment 446612 [details]
In answer to your queries:
1. In this particular instance, I had the pointer tool selected, but I don't
think I had any points selected. However, when seeing this crash, I usually do
have one or more points selected, and the crash happens then too (while trying
to move, cut, copy or paste points). So, the crash has happened both with and
without any point selections.
2. I just tested a number of fonts in order to answer this. It doesn't happen
in every font. The fonts I see the instability in - STD and TTF alike - appear
to all have glyphs in one of the Private Use planes. Whenever I tested a glyph
in Plane 15 (where I've been doing almost all of my glyph design), the crash
happened every time. Testing glyphs in the BMP and SMP didn't seem to cause any
problem, even in unassigned codepoints and blocks (though I haven't tested the
BMP's Private Use Area).
3. The ./FontForge/prefs file is posted as an attachment.
4. The problem doesn't appear to be with a particular font; however, just in
case it actually is a font problem, I'll send you (privately) the font I've
seen the bulk of the crashes with.
Thank you very much for all your help on this. It's much appreciated :-)
This seems to be a straightforward access off the end of an array when some Unicode properties are checked for the current glyph if you are using characters in Plane 16, Supplementary Private Use Area B.
I've just reported this upstream, as it occurs in latest CVS too.
Looking through recent messages here, I can see that Pablo Rodriguez
reported a crash at the same point to fontforge-users on 2010-08-17. He
was using Asana Math, which can be downloaded here:
In his case, the problem can be seen in the main window by setting Compact
encoding and scrolling down, but you can also edit one of the alternates
from the PUA and pressing any alphanumeric or try to open the Element
[Two minutes later...]
Actually, I think I know what the right thing to do is here, so I'm submitting patch upstream.
*** Bug 640575 has been marked as a duplicate of this bug. ***
Did this fix land in 20100501? or is it only still in CVS?
(In reply to comment #7)
> Did this fix land in 20100501? or is it only still in CVS?
I supplied the patch in September, so it didn't land in the May build :-P
Specifically, it is a single line change to fvcomposit.c, which was applied in revision 1.67.
The same patch applies to F13 (20090923) and F14 (20100501).
ok. Should I backport this to f13/f14? Or is a fix in rawhide good enough?
*** Bug 677014 has been marked as a duplicate of this bug. ***
Kevin, may I suggest applying the patch from comment 8 to F14, as it has now occurred there as well?
fontforge-20100501-7.fc15 has been submitted as an update for Fedora 15.
fontforge-20100501-7.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update fontforge'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/fontforge-20100501-7.fc15
fontforge-20100501-6.fc14 has been submitted as an update for Fedora 14.
fontforge-20100501-7.fc14 has been submitted as an update for Fedora 14.
Created attachment 480000 [details]
Font with glyphs outside BMP
Better late than never, here is a font that provokes the crash and proves the fix.
To reproduce, simply load FontForge with this font. You'll see a compact view of the glyphs, just three of them. Pressing Page Down will highlight the last one of the three, and pressing it again will crash FontForge.
You can get the same crash by uncompacting the glyph view (Encoding -> Compact) and using your mouse to scroll through the glyphs, though it'll take you longer to do.
I use f14 now,,
fontforge-20100501-7.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
fontforge-20100501-7.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.