Using Gdb debugger, how should I proceed to find out the cause of “Program terminated with signal 11, Segmentation fault.”

Question

Here is the backtrace of gdb,

Program terminated with signal 11, Segmentation fault.
#0  0xb7e78830 in Gtk::Widget::get_width () from /usr/lib/libgtkmm-2.4.so.1
(gdb) bt
#0  0xb7e78830 in Gtk::Widget::get_width () from /usr/lib/libgtkmm-2.4.so.1
#1  0x08221d5d in sigc::bound_mem_functor0<bool, videoScreen>::operator() (this=0xb1c04714)
    at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787`enter code here`
#2  0x08221d76 in sigc::adaptor_functor<sigc::bound_mem_functor0<bool, videoScreen> >::operator() (this=0xb1c04710)
    at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251
#3  0x08221d96 in sigc::internal::slot_call0<sigc::bound_mem_functor0<bool, videoScreen>, bool>::call_it (rep=0xb1c046f8)
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h:103
#4  0xb7b1ed35 in ?? () from /usr/lib/libglibmm-2.4.so.1
#5  0xb73c6bb6 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb28ff1f8 in ?? ()
#7  0xb647479c in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0
#8  0xb73c6446 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#9  0xb73c97e2 in ?? () from /usr/lib/libglib-2.0.so.0
#10 0xb3d11af8 in ?? ()
#11 0x00000000 in ?? ()

I figured out the line of crash,here is the code around that line.

1:currPicLoaded = 1;
2:int status = -1;
3:zoomedPicWidth = drawVideo1->get_width();    

I figured out that above line is 3 is the cause of crash, but this line execute 5 times before crash.So I do not know why it does crash at 6th time. PS : Above line of code is with in a thread which run continuously.

Any help is more than welcome :)

Answer 1

how should I proceed

Your very first step should be to find out which instruction caused the SIGSEGV . Do this:

 (gdb) x/i $pc

The most likely cause is that your drawVideo1 object is either dangling (has been deleted), or is corrupt in some other way.

Since you are apparently on Linux (you didn't say, but you should always say), the first tool to reach for for debugging "strange" problems like this is Valgrind .