In general: It is always a good idea to tell us your version of GTK/Glib installed on your system.
To create a meaningful backtrace you'll need a binary with the debugging symbols attached. Otherwise your backtrace will contain a lot of question marks and won't be useful.
Compile with debugging symbols from source
Get the source. To compile it with debugging symbols, CFLAGS must contain -g. You should also use the -O0 -fno-inline -fno-omit-frame-pointer optimization flags there.
$ ./configure CFLAGS="-g3 -O0 -fno-inline -fno-omit-frame-pointer" && make
The stable version of bluefish, namely 1.0.X at the time of writing, currently strips the debugging symbols during the installation step (make install). In this case only re-compile the sources and run the resulting binary src/bluefish in the GNU Debugger.
Install debugging symbols on Debian/Ubuntu systems
DEB_BUILD_OPTIONS="nostrip noopt" fakeroot apt-get -b source bluefish
For the current development series 1.3 the Debian and Ubuntu packages come with a package shipping the debugging symbols: bluefish-unstable-dbg. Just install it the usual way. You might need some more packages of this type: libc6-dbg, libglib2.0-0-dbg, libgtk2.0-0-dbg or libgtk-3-0-dbg, libxml2-dbg. This requires some space on your harddrive, but will help us to track down your problem and help you.
Install debugging symbols on Fedora
debuginfo-install gtk3 libxml2
to get all debug libraries installed
Run Bluefish in the debugger
Create a meaningful backtrace
To run Bluefish in the GNU Debugger, use:
Then ((gdb) represents the gdb shell prompt!):
(gdb) set logging on Copying output to gdb.txt. (gdb) r
This will start bluefish. Now reproduce the crash and then create the backtrace:
Program received signal SIGSEGV, Segmentation fault. ... (gdb) bt full ... (gdb) quit
What other information you should provide to the developers
- the platform you are using
- the gtk version you are using
- the compiler version you are using
- any non-default ./configure options
- the pcre version you are using if you think that is related
- the libaspell version you are using if you think that is related
- the gnome-vfs version you are using if you think that is related (only 1.0 series)
Debugging a Gtk-Critical error
If you set the environment variable G_DEBUG to fatal_criticals, e.g.
with bash, it should assert when there is an error. Then launch bluefish with gdb as told you above and you can get a backtrace.
You can set it to fatal_warnings too, however: it will then stop at the first warning, and bluefsh will also give warnings on problems in the language file and such, so this debugging technique is not always useful.
Running bluefish in valgrind
valgrind is a very powerful memory analyser. It makes your program very slow, but it will give very useful logging for each and every possible memory error. Make sure you set the preferences of your terminal to have a lot of lines in the buffer so you can send all of the output to the Bluefish developers!
Run valgrind like this:
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --num-callers=32 src/bluefish
More information on gtk and valgrind can be found at http://live.gnome.org/Valgrind
Download gobject-list.c from http://people.gnome.org/~mortenw/gobject-list.c and compile as is shown in the headers
to see all GObject's that are created or finalized:
to see all refcount changes on GtkTreeModelSort:
LD_PRELOAD=libgobject-list.so GOBJECT_LIST_FILTER=GtkTreeModelSort GOBJECT_LIST_DISPLAY=all src/bluefish