Difference between revisions of "Stack Trace"

From GnuCash
Jump to: navigation, search
(Links to related topics)
(General clarification and better ordering of sections. Removed obsolete instructions.)
Line 1: Line 1:
  
 
== What is a Stack Trace? ==
 
== What is a Stack Trace? ==
−
If GnuCash terminates abnormally (i. e. it crashes), then a ''stack trace'' is a very helpful information for the developers to figure out the program error that caused this crash.
+
A stack trace lists the chain of function calls leading to a point in a program's execution. Here's an example from Mac OS X; other operating systems will display the information a bit differently:
 +
  Exception Type:        EXC_CRASH (SIGABRT)
 +
  Exception Codes:      0x0000000000000000, 0x0000000000000000
 +
 
 +
  Application Specific Information:
 +
  abort() called
 +
 
 +
  Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 +
  0  libsystem_kernel.dylib        0x9769169a __pthread_kill + 10
 +
  1  libsystem_pthread.dylib      0x9836bf19 pthread_kill + 101
 +
  2  libsystem_c.dylib            0x9bde5eee abort + 156
 +
  3  libglib-2.0.0.dylib          0x02b5dd8a g_assertion_message + 346
 +
  4  libglib-2.0.0.dylib          0x02b5e470 g_assertion_message_expr + 96
 +
  5  libgncmod-gnome-utils.dylib  0x0029ec4a gnc_main_window_init + 2650
 +
  6  libgobject-2.0.0.dylib        0x02ae7496 g_type_create_instance + 470
 +
  7  libgobject-2.0.0.dylib        0x02ad51a2 g_object_new_internal + 562
 +
  8  libgobject-2.0.0.dylib        0x02ad5a90 g_object_newv + 480
 +
  9  libgobject-2.0.0.dylib        0x02ad5b7d g_object_new + 61
 +
  10  libgncmod-gnome-utils.dylib  0x002a03d7 gnc_main_window_new + 39
 +
  11  libgncmod-gnome-utils.dylib  0x0029a6f5 gnc_gui_init + 581
 +
  12  Gnucash-bin                  0x00011387 main + 1143
 +
  13  Gnucash-bin                  0x00010ed6 start + 54
  
−
Additionally, some interesting logging messages are written into the [[Tracefile]] at each run of GnuCash.
+
This shows why GnuCash crashed (an assertion failed in the main window init function); without a stack trace crashes can be very difficult to diagnose. Developers will usually also ask for the [[Tracefile]], which will often provide additional useful information. In the case above we'd find the actual assertion message that would explain the abort.
−
 
 
−
=== MacOSX is Easiest ===
 
−
Every time an application crashes in MacOSX, the system writes a crash report with a stack trace to <tt>$HOME/Library/Logs/DiagnosticReports</tt> or <tt>$HOME/Library/Logs/CrashReporter</tt>, or both, depending on what version of OSX you're running. The crash reports are easily viewed with <tt>Applications:Utilities:Console</tt>, and if you're reporting a crash in Bugzilla or to the user's list you should attach one to your report.  
 
  
 
=== Better with Debugging Symbols ===
 
=== Better with Debugging Symbols ===
−
A stack trace can be obtained in several different levels of verbosity. By default, most distributions will enable only a very coarse stack trace where not much information is shown about each of the stack levels. The stack trace gets much more useful if '''debugging symbols''' are available.  Please try to enable them, if possible. If you are running GnuCash
+
A stack trace can be obtained in several different levels of verbosity. By default, most distributions will enable only a very coarse stack trace where not much information is shown about each function. The stack trace gets much more useful if '''debugging symbols''' are available.  Please try to enable them, if possible. If you are running GnuCash
−
* from a ''ready made package'', search with your package manager for the corresponding '''-dbg''' or -debug package and install it.  
+
* from a ''ready made package on Linux'', search with your package manager for the corresponding '''-dbg''' or '''-debug''' package and install it.  
 
** If other packages like AqBanking are used, try to find and install their corresponding -dbg packages, too. If your problem is solved, you can uninstall them again.
 
** If other packages like AqBanking are used, try to find and install their corresponding -dbg packages, too. If your problem is solved, you can uninstall them again.
−
* ''self made'' from the sources, add '''--enable-debug''' to your ''configure'' options and redo the make process.
+
* When built locally from the sources, add '''--enable-debug''' to your ''configure'' options and redo the make process.
 +
 
 +
== How to obtain a Stack Trace ==
 +
 
 +
=== MacOSX ===
 +
Every time an application crashes in Mac OS X, the system writes a crash report with a stack trace to <tt>$HOME/Library/Logs/DiagnosticReports</tt> or <tt>$HOME/Library/Logs/CrashReporter</tt>, or both, depending on what version of OS X you're running. The crash reports are easily viewed with <tt>Applications:Utilities:Console</tt>, and if you're reporting a crash in Bugzilla or to the user's list you should attach one to your report.  
  
−
=== Also on Windows? ===
+
=== Linux ===
−
However, on [[Windows]] it is currently not so easy to obtain such a stack trace. Some explanation on how to do this for experts is below, but we are aware of the fact that this is rather difficult for the average user. If you have been asked to provide a stack trace, but you are using GnuCash on Windows only and feel too unfamiliar with gdb debugging, please respond along the lines of "I'm sorry, but I encountered this problem only on Windows and I am not familiar enough with gdb on Windows to obtain stack traces there". Thanks a lot. Nevertheless, in many cases your bugreport can only be worked on if you or someone else can actually produce such a stack trace.
+
In order to get a stack trace on Linux one must have either the GNU Debugger, gdb, or the LLVM Debugger, lldb, installed. Use your package manager to install one or the other if necessary. Gdb is a bit simpler to use, so the instructions below are for gdb.
  
−
== How to obtain a Stack Trace ==
+
There are two ways to put GnuCash under the debugger's control. Starting GnuCash under the debugger is a bit more straightforward, but the debugger slows down the program quite a bit so it might work better for you to start GnuCash as usual, get to the point where some action provokes the crash, then attach the debugger to the running GnuCash.
−
There are two possibilities to obtain a stack trace. You can choose either one, whichever seems easier or works better for you.
 
  
−
=== Attach gdb to running process ===
+
==== Starting GnuCash under gdb ====
−
The program "gnucash" itself is not an executable but a script. Therefore it cannot be called directly by the ''gdb'' debugger. We propose to "attach" the gdb to the running gnucash process instead.
 
  
−
To attach to the running gnucash process:
+
# run <tt>gdb gnucash</tt>
 +
# at the ''gdb'' prompt, type: "run". If you need to pass command line arguments, add them here, e.g. "run --nofile"
  
−
# Start gnucash normally
+
==== Attach gdb to running process ====
−
# Use "ps afx" (some people prefere "ps aux") to find out the process number (PID) of the running gnucash process; it might be called "gnucash" or "gnucash-bin". Say the PID is 12345.
 
−
# Start gdb by typing "gdb"
 
−
# Attach to the running process by typing "attach 12345"; gdb will temporarily stop the program
 
−
# Continue program execution by typing "continue" at the "(gdb)" prompt
 
−
# Provoke the crash; type "backtrace" or shorthand "bt" at the gdb prompt to obtain the backtrace ("bt full" might provide additional info about local variables).
 
  
−
Please submit the backtrace together with the instructions on how to reproduce this crash as a new bug report into [[Bugzilla]]. Thank you for your contribution.
+
# Start gnucash normally.
 +
# In a terminal window run <tt>ps afx</tt> (some people prefer <tt>ps aux</tt>) to find out the process number (PID) of the running gnucash process; it might be called "gnucash" or "gnucash-bin". Say the PID is 12345.
 +
# Run <tt>gdb gnucash</tt>
 +
# Attach to the running process by typing <tt>attach 12345</tt>; gdb will temporarily stop the program
 +
# Continue program execution by typing <tt>c</tt> at the "(gdb)" prompt
  
−
=== Starting GnuCash under gdb ===
+
==== Obtain the stack trace ====
 +
# Provoke the crash. When GnuCash crashes gdb will print the reason for the crash and present the "(gdb)" prompt again.
 +
# Type <tt>bt</tt> (<tt>bt full</tt> might provide additional info about local variables).
 +
# Gdb will print the backtrace.
  
−
Sometimes GnuCash might crash too early in the startup sequence such that you cannot attach gdb to the running process.  In that case you can run gnucash under gdb. This is much easier as of GnuCash 2.0.  To run GnuCash under gdb from the beginning:
+
==== Exit Gdb ====
 +
<tt>ctrl-d</tt> or <tt>quit</tt> will end the gdb session.
  
−
# run "gnucash-env gdb gnucash"
+
Please copy and paste the error and stack trace from the terminal into a bug report; see [[Bugzilla]] for details about creating a new one if you haven't already.
−
# at the ''gdb'' prompt, type: "run". Also add your parameters here, like "run --nofile"
 
−
# Provoke the crash; type "backtrace" or shorthand "bt" at the gdb prompt to obtain the backtrace ("bt full" might provide additional info about local variables).
 
  
 
=== Windows ===
 
=== Windows ===
 +
On [[Windows]] it is currently not so easy to obtain such a stack trace. Some explanation on how to do this for experts is below, but we recognize that this is rather difficult for the average user. If you have been asked to provide a stack trace, but you are using GnuCash on Windows only and find these instructions too daunting, please respond along the lines of "I'm sorry, but I encountered this problem only on Windows and I am not familiar enough with gdb on Windows to obtain stack traces there". Thanks a lot. Nevertheless, in many cases your bugreport can only be worked on if you or someone else can actually produce such a stack trace.
 
 
 
 
−
Here are a few instructions on how to run gnucash under gdb on Windows:
 
 
* Install "gdb" from mingw.org [http://downloads.sourceforge.net/mingw/gdb-7.6.1-1.exe]
 
* Install "gdb" from mingw.org [http://downloads.sourceforge.net/mingw/gdb-7.6.1-1.exe]
−
* '''GnuCash 2.2.9 and older'''
+
* Open a Windows command prompt and type:
−
:* Modify the installed "bin\gnucash.cmd" script by inserting one and changing one line.  It should end like
 
−
    set PATH=C:\Program Files\gdb\bin;%PATH%
 
−
    start gdb --args gnucash-bin %*
 
−
::Be careful to use the actual paths in which you have installed gdb.exe
 
−
:* Then start gnucash as usual
 
−
*'''GnuCash 2.4.0 and more recent'''
 
−
:* Open a Windows command prompt and type:
 
 
     set PATH=C:\Program Files\gdb\bin;%PATH%
 
     set PATH=C:\Program Files\gdb\bin;%PATH%
 
     gdb "C:\Program Files\gnucash\bin\gnucash"
 
     gdb "C:\Program Files\gnucash\bin\gnucash"
−
::Be careful to use the actual paths in which you have installed gdb and gnucash respectively.
+
:Be careful to use the actual paths in which you have installed gdb and gnucash respectively.
−
*'''For all versions''': this will open a gdb prompt
+
* [[#Obtain the stack trace]] with the instructions above.
−
* Type <tt>run</tt> at the gdb prompt.
 
−
* Then provoke the crash and type <tt>backtrace</tt> or shorthand <tt>bt</tt> at the gdb prompt to obtain the backtrace, as explained on [[Stack Trace]] as well.
 
  
 
If you build gnucash with the help of install.sh, make sure you export <tt>DISABLE_OPTIMIZATIONS=yes</tt> in <tt>packaging/win32/custom.sh</tt> to include debugging symbols and avoid optimizations that complicate debugging.
 
If you build gnucash with the help of install.sh, make sure you export <tt>DISABLE_OPTIMIZATIONS=yes</tt> in <tt>packaging/win32/custom.sh</tt> to include debugging symbols and avoid optimizations that complicate debugging.

Revision as of 19:32, 25 April 2015

What is a Stack Trace?

A stack trace lists the chain of function calls leading to a point in a program's execution. Here's an example from Mac OS X; other operating systems will display the information a bit differently: 

 Exception Type:        EXC_CRASH (SIGABRT)
 Exception Codes:       0x0000000000000000, 0x0000000000000000
 
 Application Specific Information:
 abort() called
 
 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   libsystem_kernel.dylib        	0x9769169a __pthread_kill + 10
 1   libsystem_pthread.dylib       	0x9836bf19 pthread_kill + 101
 2   libsystem_c.dylib             	0x9bde5eee abort + 156
 3   libglib-2.0.0.dylib           	0x02b5dd8a g_assertion_message + 346
 4   libglib-2.0.0.dylib           	0x02b5e470 g_assertion_message_expr + 96
 5   libgncmod-gnome-utils.dylib   	0x0029ec4a gnc_main_window_init + 2650
 6   libgobject-2.0.0.dylib        	0x02ae7496 g_type_create_instance + 470
 7   libgobject-2.0.0.dylib        	0x02ad51a2 g_object_new_internal + 562
 8   libgobject-2.0.0.dylib        	0x02ad5a90 g_object_newv + 480
 9   libgobject-2.0.0.dylib        	0x02ad5b7d g_object_new + 61
 10  libgncmod-gnome-utils.dylib   	0x002a03d7 gnc_main_window_new + 39
 11  libgncmod-gnome-utils.dylib   	0x0029a6f5 gnc_gui_init + 581
 12  Gnucash-bin                   	0x00011387 main + 1143
 13  Gnucash-bin                   	0x00010ed6 start + 54

This shows why GnuCash crashed (an assertion failed in the main window init function); without a stack trace crashes can be very difficult to diagnose. Developers will usually also ask for the Tracefile, which will often provide additional useful information. In the case above we'd find the actual assertion message that would explain the abort.

Better with Debugging Symbols

A stack trace can be obtained in several different levels of verbosity. By default, most distributions will enable only a very coarse stack trace where not much information is shown about each function. The stack trace gets much more useful if debugging symbols are available. Please try to enable them, if possible. If you are running GnuCash

  • from a ready made package on Linux, search with your package manager for the corresponding -dbg or -debug package and install it.
    • If other packages like AqBanking are used, try to find and install their corresponding -dbg packages, too. If your problem is solved, you can uninstall them again.
  • When built locally from the sources, add --enable-debug to your configure options and redo the make process.

How to obtain a Stack Trace

MacOSX

Every time an application crashes in Mac OS X, the system writes a crash report with a stack trace to $HOME/Library/Logs/DiagnosticReports or $HOME/Library/Logs/CrashReporter, or both, depending on what version of OS X you're running. The crash reports are easily viewed with Applications:Utilities:Console, and if you're reporting a crash in Bugzilla or to the user's list you should attach one to your report.

Linux

In order to get a stack trace on Linux one must have either the GNU Debugger, gdb, or the LLVM Debugger, lldb, installed. Use your package manager to install one or the other if necessary. Gdb is a bit simpler to use, so the instructions below are for gdb.

There are two ways to put GnuCash under the debugger's control. Starting GnuCash under the debugger is a bit more straightforward, but the debugger slows down the program quite a bit so it might work better for you to start GnuCash as usual, get to the point where some action provokes the crash, then attach the debugger to the running GnuCash.

Starting GnuCash under gdb

  1. run gdb gnucash
  2. at the gdb prompt, type: "run". If you need to pass command line arguments, add them here, e.g. "run --nofile"

Attach gdb to running process

  1. Start gnucash normally.
  2. In a terminal window run ps afx (some people prefer ps aux) to find out the process number (PID) of the running gnucash process; it might be called "gnucash" or "gnucash-bin". Say the PID is 12345.
  3. Run gdb gnucash
  4. Attach to the running process by typing attach 12345; gdb will temporarily stop the program
  5. Continue program execution by typing c at the "(gdb)" prompt

Obtain the stack trace

  1. Provoke the crash. When GnuCash crashes gdb will print the reason for the crash and present the "(gdb)" prompt again.
  2. Type bt (bt full might provide additional info about local variables).
  3. Gdb will print the backtrace.

Exit Gdb

ctrl-d or quit will end the gdb session.

Please copy and paste the error and stack trace from the terminal into a bug report; see Bugzilla for details about creating a new one if you haven't already.

Windows

On Windows it is currently not so easy to obtain such a stack trace. Some explanation on how to do this for experts is below, but we recognize that this is rather difficult for the average user. If you have been asked to provide a stack trace, but you are using GnuCash on Windows only and find these instructions too daunting, please respond along the lines of "I'm sorry, but I encountered this problem only on Windows and I am not familiar enough with gdb on Windows to obtain stack traces there". Thanks a lot. Nevertheless, in many cases your bugreport can only be worked on if you or someone else can actually produce such a stack trace.

  • Install "gdb" from mingw.org [1]
  • Open a Windows command prompt and type:
   set PATH=C:\Program Files\gdb\bin;%PATH%
   gdb "C:\Program Files\gnucash\bin\gnucash"
Be careful to use the actual paths in which you have installed gdb and gnucash respectively.

If you build gnucash with the help of install.sh, make sure you export DISABLE_OPTIMIZATIONS=yes in packaging/win32/custom.sh to include debugging symbols and avoid optimizations that complicate debugging.

You can provide even better stack traces if you tell gdb where in memory dynamically loaded modules got mapped to, because otherwise function calls into those are only written as '??'. See here and here for a way to do this.

To enter [ and ], use set editing off.


See also

Other explanations on how to obtain stack traces:

Debug symbol information

Gnucash needs to be compiled in a way that has the debug symbols still included in the resulting binary libraries. When compiling gnucash from the tarball yourself, this is achieved by using the configure option ./configure --enable-debug.

Gentoo

When emerging gnucash on gentoo, you need to make sure that

  1. the "debug" USE flag is enabled
  2. and "FEATURES=nostrip" is set to disable symbol stripping.

Ubuntu / Debian

On Ubuntu, the debug symbols are available in a separate package called gnucash-dbg. See https://wiki.ubuntu.com/DebuggingProgramCrash

This issue is also explained here https://wiki.ubuntu.com/Backtrace.

Tracefile Logging Bugzilla#Using Bugzilla FAQ#Q: How do I run GnuCash under gdb and get a stack trace?
Retrieved from "https://wiki.gnucash.org/wiki/index.php?title=Stack_Trace&oldid=11758"