Debugging Bluefish: Difference between revisions
Line 19: | Line 19: | ||
=== Install debugging symbols on Debian/Ubuntu systems === | === Install debugging symbols on Debian/Ubuntu systems === | ||
For Debian and Ubuntu there are packages available with debugging symbols. This package is called bluefish-dbg. Just install it the usual way, for example from the commandline with "apt-get install bluefish-dbg" | |||
You might need some more packages of this type: '''libc6-dbg''', '''libglib2.0-0-dbg''', '''libgtk-3-0-dbg''', '''libpcre3-dbg''', '''libxml2-dbg'''. | |||
== Run Bluefish in the debugger == | == Run Bluefish in the debugger == |
Revision as of 19:46, 13 April 2015
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
For more information about compiling from source, see Compiling Bluefish from source.
The stable version of bluefish, namely 2.2.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
For Debian and Ubuntu there are packages available with debugging symbols. This package is called bluefish-dbg. Just install it the usual way, for example from the commandline with "apt-get install bluefish-dbg"
You might need some more packages of this type: libc6-dbg, libglib2.0-0-dbg, libgtk-3-0-dbg, libpcre3-dbg, libxml2-dbg.
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/>