Debugging Bluefish

From Bluefish Wiki
Jump to navigation Jump to search


In general: It is always a good idea to tell us your version of GTK/Glib installed on your system.

Debugging symbols

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 optimization flag there.
$ ./configure CFLAGS="-g -O0" && 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

To receive debugging symbols for the 1.0 stable series of bluefish in Debian/Ubuntu the sources must be recompiled without stripping the resulting binary. This is done by following these steps <ref>More to find in the Debian Wiki</ref>:

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, libpcre3-dbg, libxml2-dbg. This requires some space on your harddrive, but will help us to track down your problem and help you.

Run Bluefish in the debugger

Create a meaningful backtrace

To run Bluefish in the GNU Debugger, use:

gdb bluefish

or for the 1.0 series (see above):

gdb src/bluefish

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

Now you'll find a file gdb.txt in the directory. Open a report in our BTS and attach this file to the report. This is what a Backtrace Should Look Like.

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_warnings, e.g.

export G_DEBUG=fatal_warnings

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.

Notes and references

References: <references/>