Debugging Bluefish: Difference between revisions

From Bluefish Wiki
Jump to navigation Jump to search
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
__TOC__
__TOC__


= Providing information =


In general: It is always a good idea to tell us your version of '''GTK/Glib installed''' on your system.
In general: It is always a good idea to tell us your version of Bluefish and your version of '''GTK/Glib installed''' on your system, both can be found in the '''About''' menu. Also don't forget to mention the platform (Linux, OSX, Windows, FreeBSD, etc.) and it's version. If you have the possibility to test it on multiple computers with different platforms or versions this will really help to track down the problem. If you can reproduce a crash on some specific file, please send us the file too. The smaller the file, the easier for us to debug the issue.
 
Crash reports / bugs are collected here: https://bugzilla.gnome.org/page.cgi?id=browse.html&product=bluefish
 
= Specific crash information =


== Debugging symbols  ==
== Debugging symbols  ==
Line 10: Line 15:
=== Compile with debugging symbols from source ===
=== Compile with debugging symbols from source ===


[http://bfwiki.tellefsen.net/index.php/Getting_Bluefish#Downloading_the_source Get the source]. To compile it with debugging symbols, CFLAGS must contain '''-g'''. You should also use the '''-O0''' optimization flag there.<br />
[http://bfwiki.tellefsen.net/index.php/Getting_Bluefish#Downloading_the_source Get the source].  
<tt>$ ./configure CFLAGS="-g -O0" && make</tt>


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.
The Bluefish makefile strips the debugging symbols during the installation step ('''make install'''). In this case only re-compile the sources, run make install to install required files (in /usr/local/share/bluefish) and then run the resulting binary from the compile directory '''src/bluefish''' in the GNU Debugger.


=== Install debugging symbols on Debian/Ubuntu systems ===
=== Install debugging symbols on Debian/Ubuntu systems ===


To receive debugging symbols for the 1.0 stable series of bluefish in [http://packages.debian.org/bluefish Debian]/[http://packages.ubuntu.com/bluefish  Ubuntu] the sources must be recompiled without stripping the resulting binary. This is done by following these steps <ref>More to find in the [http://wiki.debian.org/HowToGetABacktrace Debian Wiki]</ref>:
For Debian and Ubuntu there might be 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". If they are not available for your distribution or version you have to compile from source.


DEB_BUILD_OPTIONS="nostrip noopt" fakeroot apt-get -b source bluefish
You might need some more packages of this type: '''libc6-dbg''', '''libglib2.0-0-dbg''', '''libgtk-3-0-dbg''', '''libpcre3-dbg''', '''libxml2-dbg'''.
 
For the current development series 1.3 the [http://debian.wgdd.de/debian/ Debian] and [http://debian.wgdd.de/debian/#ubuntu 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 ==
== Run Bluefish in the debugger ==
Line 27: Line 29:
=== Create a meaningful backtrace ===
=== Create a meaningful backtrace ===


To run Bluefish in the GNU Debugger, use:
To run Bluefish in the GNU Debugger (assuming you have just compiled it, and ran make install), use:
 
gdb bluefish
 
or for the '''1.0 series''' (see above):


  gdb src/bluefish
  gdb src/bluefish
Line 50: Line 48:


Now you'll find a file '''gdb.txt''' in the directory. [https://bugzilla.gnome.org/enter_bug.cgi?product=bluefish Open a report in our BTS] and attach this file to the report. This is what a [[Backtrace Should Look Like]].
Now you'll find a file '''gdb.txt''' in the directory. [https://bugzilla.gnome.org/enter_bug.cgi?product=bluefish 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 ===
=== Debugging a Gtk-Critical error ===
Line 69: Line 57:
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.
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 ==
= debugging on windows =
mypaint has a good tutorial: https://github.com/mypaint/mypaint/wiki/Debugging-crashes-on-Windows
 
 


References: <references/>
References: <references/>

Revision as of 20:48, 1 May 2017

Providing information

In general: It is always a good idea to tell us your version of Bluefish and your version of GTK/Glib installed on your system, both can be found in the About menu. Also don't forget to mention the platform (Linux, OSX, Windows, FreeBSD, etc.) and it's version. If you have the possibility to test it on multiple computers with different platforms or versions this will really help to track down the problem. If you can reproduce a crash on some specific file, please send us the file too. The smaller the file, the easier for us to debug the issue.

Crash reports / bugs are collected here: https://bugzilla.gnome.org/page.cgi?id=browse.html&product=bluefish

Specific crash information

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.

The Bluefish makefile strips the debugging symbols during the installation step (make install). In this case only re-compile the sources, run make install to install required files (in /usr/local/share/bluefish) and then run the resulting binary from the compile directory src/bluefish in the GNU Debugger.

Install debugging symbols on Debian/Ubuntu systems

For Debian and Ubuntu there might be 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". If they are not available for your distribution or version you have to compile from source.

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 (assuming you have just compiled it, and ran make install), use:

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.

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.

debugging on windows

mypaint has a good tutorial: https://github.com/mypaint/mypaint/wiki/Debugging-crashes-on-Windows


References: <references/>