How to create useful backtrace on linux

product: BricsCAD
version: V10 and newer
operating system: Linux (all versions)
last reviewed: 2013-11-19


BricsCAD suddenly disappears.
When running BricsCAD from commandline, a short error message is printed (often it will be "segmentation fault").

Apart from that there is little clue why the crash happens, often developers will not be able to reproduce, as the crash can happen at unpredictable moments.

In that case a backtrace or stack trace can be very useful.


1. In a terminal, run BricsCAD in gdb with the following command:

LD_LIBRARY_PATH=/opt/bricsys/bricscad/v13 gdb /opt/bricsys/bricscad/v13/bricscad

2. In the window type 'run' (+enter) to start the program.

3. Reproduce the crash. After crashing, the BricsCAD window simply freezes, but does not disappear.

4. Switch back to the terminal and type 'bt' (+enter) to get a backtrace.
The whole backtrace might not fit the screen. In that case the last line reads like this:

---Type to continue, or q to quit---

5. Copy the relevant part of the backtrace into a file to attach it to a support request, or post it directly into the support request.

6. Type q (+enter) into terminal window and press y (+enter) to confirm.

A backtrace may look like this:

(gdb) bt
#0 0xf7fdf430 in __kernel_vsyscall ()
#1 0xf325aa01 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xf325de42 in abort () at abort.c:92
#3 0xf347b3f5 in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib32/
#4 0xf34792d5 in ?? () from /usr/lib32/
#5 0xf3479312 in std::terminate() () from /usr/lib32/
#6 0xf3479481 in __cxa_throw () from /usr/lib32/
#7 0xf341e2ef in std::__throw_out_of_range(char const*) ()
from /usr/lib32/
#8 0xf6adbef5 in wxg::LayoutTabs::tabIndexAtPoint(wxPoint) const ()
from /opt/bricsys/bricscad/v10/
#9 0xf6adcce6 in wxg::LayoutTabs::onLeftDown(wxMouseEvent&) ()
from /opt/bricsys/bricscad/v10/
#10 0xf64c6c01 in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const ()
from /opt/bricsys/bricscad/v10/
#11 0xf656623a in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) ()
from /opt/bricsys/bricscad/v10/
#12 0xf65663c6 in wxEvtHandler::SearchDynamicEventTable(wxEvent&) ()
---Type to continue, or q to quit---
from /opt/bricsys/bricscad/v10/
#13 0xf656752d in wxEvtHandler::ProcessEvent(wxEvent&) ()
from /opt/bricsys/bricscad/v10/
#14 0xf623bf6b in wxWindow::GTKProcessEvent(wxEvent&) const ()
from /opt/bricsys/bricscad/v10/
#15 0xf6241d80 in gtk_window_button_press_callback ()
from /opt/bricsys/bricscad/v10/
#16 0xf2d09284 in ?? () from /usr/lib32/
#17 0xf2907412 in g_closure_invoke () from /usr/lib32/
#18 0xf291d595 in ?? () from /usr/lib32/
#19 0xf291e83b in g_signal_emit_valist () from /usr/lib32/
#20 0xf291ee62 in g_signal_emit () from /usr/lib32/
#21 0xf2e37b96 in ?? () from /usr/lib32/
#22 0xf2d0185d in gtk_propagate_event () from /usr/lib32/
#23 0xf2d02ed7 in gtk_main_do_event () from /usr/lib32/
#24 0xf2b9336a in ?? () from /usr/lib32/
#25 0xf2856855 in g_main_context_dispatch () from /lib32/
#26 0xf285a668 in ?? () from /lib32/
#27 0xf285aba7 in g_main_loop_run () from /lib32/
#28 0xf2d031d9 in gtk_main () from /usr/lib32/
#29 0xf622caa5 in wxEventLoop::Run() ()
---Type to continue, or q to quit---
from /opt/bricsys/bricscad/v10/
#30 0xf62b3a1e in wxAppBase::MainLoop() ()
from /opt/bricsys/bricscad/v10/
#31 0xf62b35f1 in wxAppBase::OnRun() ()
from /opt/bricsys/bricscad/v10/
#32 0xf6500a4a in wxEntry(int&, wchar_t**) ()
from /opt/bricsys/bricscad/v10/
#33 0xf6500c47 in wxEntry(int&, char**) ()
from /opt/bricsys/bricscad/v10/
#34 0x0805ce4f in main ()

More information

A backtrace or stack trace can be very useful.
It shows the current stack of nested function calls at the moment of the crash, from the main (entry) function of your program to the last called function.
Normally it is only useful if you have the source code, although the name of the functions alone can give an idea of the context in which the crash occurs.

Some bugs cause crashes at a later point, sometimes even in unrelated code (eg memory corruption). In such cases a backtrace is of little or no help.

If the bug can be reproduced by a developer, a stack trace is normally no longer needed. Indeed, a stack trace is typically asked for a bug that cannot be reproduced from its description.

(credits to Mattias Põldaru for the original howto in forumpost 14080