When things go wrong with FontForge itself

If you find FontForge crashing whilst in use you might like to send information to the fontforge developer mailing list at https://lists.sourceforge.net/lists/listinfo/fontforge-devel. This way, a software developer might be able to work out where the code is going wrong and apply a fix. You can then either patch your local FontForge, or just grab the sources from github as detailed in the Installing chapter to get an updated FontForge free of the defect you reported.

To help developers find out what is going wrong, they will want a backtrace from your session. The backtrace includes a list of which program functions have called which other ones to get to where the program has stopped working. The backtrace is most useful if it also contains the line numbers of the functions. Because the backtrace will make reference to source files and line numbers, don't forget to also tell the developers which version of FontForge you are using. Optionally, you might also like to mention what you were doing leading up to the crash.

Using the GNU Debugger to report crashes

A backtrace is generated using the GNU Project Debugger (gdb). You can either attach gdb to an already running FontForge, or start fontforge inside the gdb session itself as shown below.

$ gdb fontforge
GNU gdb (GDB) Fedora (7.3.50.20110722-16.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/fontforge...done.

Then once you issue the debugger the run command, FontForge will open on screen;

(gdb) run
Starting program: /usr/local/bin/fontforge 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Copyright (c) 2000-2012 by George Williams.
 Executable based on sources from 14:57 GMT 31-Jul-2012-ML-TtfDb-D.
 Library based on sources from 14:57 GMT 31-Jul-2012.

From here you can use FontForge in the usual way, but with the advantage of being able to effectively capture and report any issues that FontForge may have.

One major difference that running FontForge inside gdb makes is how a crash is made apparent. Without gdb, when FontForge crashes it will disappear from your screen. When you are running FontForge inside gdb however, a crashed FontForge will remain open along with its windows and user interface.

If you find that your interface is unresponsive, switch back to the terminal where you ran gdb and you might see something like "SIGSEGV" in the text followed by the (gdb) prompt. If you see the (gdb) prompt then FontForge is no longer executing. At this stage, use the "bt" command to get a backtrace as shown in the example below.

As you can see in the example backtrace FontForge has crashed inside the copy() function. The copy() function was itself called from the KCD_AutoKernAClass function. The backtrace will tell a software developer the exact lines these calls were made, and also use the tip that the parameter passed to copy() was invalid (out of bounds) to work out what the code is doing wrong.

Program received signal SIGSEGV, Segmentation fault. 
0x00007ffff74a7c01 in ?? () from /lib/x86_64-linux-gnu/libc.so.

 (gdb) bt
 #0  0x00007ffff74a7c01 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6389a80 in copy (str=0x900000008