How can I figure out where and why this segmentation fault occurs? - c++

I'm having trouble figuring out the problem with my code...I'm in the early stages of prototyping a game (my first serious project). It frequently, but not always, crashes with a segmentation fault. Here's the flow of the program...
title screen - press z to start new game
player and enemy on screen...enemy takes a life when collided with, there are 4 lives.
when character's life is 0, game goes back to title screen - press z to start new game
The last step is where the crash occurs...The crash only seems to happen after the player dies and is brought back to the title screen and the player presses z to start another game, but it doesn't always crash. Through gdb, I've determined that it happens when the deconstructor for Title is called...
Here's the debug info and relevant code...I'll provide any other code/info if requested.
*** glibc detected *** /home/rzrscm/code/demogamething/game: free(): invalid pointer: 0x080c6b98 ***
//memory map info omitted
0xb7c54537 in raise () from /lib/libc.so.6
(gdb) where
#0 0xb7c54537 in raise () from /lib/libc.so.6
#1 0xb7c57922 in abort () from /lib/libc.so.6
#2 0xb7c8afbd in ?? () from /lib/libc.so.6
#3 0xb7c950ca in ?? () from /lib/libc.so.6
#4 0xb7c96918 in ?? () from /lib/libc.so.6
#5 0xb7c99a5d in free () from /lib/libc.so.6
#6 0xb7f4e776 in SDL_FreeSurface () from /usr/lib/libSDL-1.2.so.0
#7 0x0804ac7f in ~Title (this=0x80b4250, __in_chrg=<value optimized out>) at title.cpp:13
#8 0x08049d3a in GameState::load (this=0x804e368, loadState=LEVEL) at gamestate.cpp:39
#9 0x08049c5c in GameState::change (this=0x804e368, changeTo=LEVEL) at gamestate.cpp:26
#10 0x08049753 in Player::handleEvent (this=0x804e300) at player.cpp:102
#11 0x080490c8 in main () at main.cpp:27
So, what I know is that the crash occurs when it's changing states from TITLE to LEVEL...Here's the class function that unloads and loads the states...currentState is a private vector in the GameState class...
std::vector<GameState *> currentState;
void GameState::load(STATE loadState) {
if(state == TITLE) {
while(!currentState.empty()) {
delete currentState.back();
currentState.pop_back();
}
currentState.push_back(new Title());
}
else if(state == LEVEL) {
while(!currentState.empty()) {
delete currentState.back();
currentState.pop_back();
}
currentState.push_back(new Level(currentLevel));
}
}
The crash happens when the deconstructor for the Title class is called...It happens whether it's freeing the music or the image...Whichever one is the first function is the one it crashes on.
Title::~Title() {
SDL_FreeSurface(background);
Mix_FreeMusic(music);
background = NULL;
music = NULL;
}
Here's the code for the image loading function...
SDL_Surface *loadImage(std::string imageFile) {
SDL_Surface *loadedImage;
SDL_Surface *newImage;
loadedImage = IMG_Load(imageFile.c_str());
newImage = SDL_DisplayFormatAlpha(loadedImage);
SDL_FreeSurface(loadedImage);
return newImage;
}
[edit] I ran it through the debugger a couple more times without making changes to the code since I still can't find what's wrong...And each time the crash occurred while trying to free the music...
0xb7c54537 in raise () from /lib/libc.so.6
(gdb) backtrace
#0 0xb7c54537 in raise () from /lib/libc.so.6
#1 0xb7c57922 in abort () from /lib/libc.so.6
#2 0xb7c8afbd in ?? () from /lib/libc.so.6
#3 0xb7c950ca in ?? () from /lib/libc.so.6
#4 0xb7c9633e in ?? () from /lib/libc.so.6
#5 0xb79974e2 in ?? () from /usr/lib/libmikmod.so.2
#6 0xb7997640 in Player_Free () from /usr/lib/libmikmod.so.2
#7 0xb7ebb6e3 in Mix_FreeMusic () from /usr/lib/libSDL_mixer-1.2.so.0
#8 0x0804ac8d in ~Title (this=0x80c6bc0, __in_chrg=<value optimized out>) at title.cpp:14
#9 0x08049d3a in GameState::load (this=0x804e368, loadState=LEVEL) at gamestate.cpp:39
#10 0x08049c5c in GameState::change (this=0x804e368, changeTo=LEVEL) at gamestate.cpp:26
#11 0x08049753 in Player::handleEvent (this=0x804e300) at player.cpp:102
#12 0x080490c8 in main () at main.cpp:27

#5 0xb7c99a5d in free () from /lib/libc.so.6
#6 0xb7f4e776 in SDL_FreeSurface () from /usr/lib/libSDL-1.2.so.
You are probably freeing a pointer which is invalid. Now I read
free(): invalid pointer: 0x080c6b98
You might be trying to free an object which was not allocated dynamically. How does background get his value?

Related

Boost iostreams long time to open memory mapped file

When I call open on a boost::iostreams::mapped_file_source my program hangs for around two minutes. I tried attaching gdb to the process at this point and the backtrace shows
(gdb) backtrace
#0 0x00007f779226687a in mmap64 () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f7793c60f58 in boost::iostreams::detail::mapped_file_impl::try_map_file(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#2 0x00007f7793c61028 in boost::iostreams::detail::mapped_file_impl::map_file(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>&) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#3 0x00007f7793c614d2 in boost::iostreams::detail::mapped_file_impl::open(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#4 0x00007f7793c6168e in boost::iostreams::mapped_file_source::open_impl(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path> const&) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#5 0x0000000000e07f86 in boost::iostreams::mapped_file_source::open<boost::iostreams::detail::path> (this=this#entry=0x1db63f8, p=...) at /usr/include/boost/iostreams/device/mapped_file.hpp:406
#6 0x0000000000e08011 in boost::iostreams::mapped_file_source::open<boost::filesystem::path> (this=this#entry=0x1db63f8, path=..., length=length#entry=18446744073709551615, offset=offset#entry=0)
at /usr/include/boost/iostreams/device/mapped_file.hpp:416
Why is the call to open so slow here? Shouldn't it return quickly here?

Why mingw+gdb cannot show backtrace correctly from inside a sigsegv handler?

I'm debugging a process that runs really slow when is executed from gdb on Windows (mingw32), so I decided to run it until it crash without gdb, and then to attach the debugger. I've installed a signal handler for sigsegv that shows its pid and waits, so when I see the message I load gdb and use the "attach" command with that pid. The problem is that gdb shows me an useless backtrace at that point. Here's an example:
void my_sigsegv_handler(int) {
std::cerr << "Segmentation fault! pid=" << GetCurrentProcessId();
std::cin.get(); // wait for gdb
}
int main() {
signal(SIGSEGV,my_sigsegv_handler);
int *p = 0;
std::cout << *p; // boom!
}
Compiled with "mingw32-g++ -g -O0", output from gdb's command "bt" (after selecting the proper thread) is:
#0 0x764e73ea in ?? ()
#1 0x7646f489 in ?? ()
#2 0x75edc3b3 in ?? ()
#3 0x75edc2bc in ?? ()
#4 0x75edc472 in ?? ()
#5 0x00415502 in __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::uflow() ()
#6 0x00434f32 in std::istream::get() ()
#7 0x004016d5 in my_sigsegv_handler () at C:\Users\usuario\zinjai\sin_titulo.cpp:8
#8 0x004010f9 in _gnu_exception_handler (exception_data=0x28fa88) at ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c:137
#9 0x76469d57 in ?? ()
#10 0x77100727 in ?? ()
#11 0x770c9d45 in ?? ()
#12 0x00000000 in ?? ()
Notice that this example does not corrupt stack when generating the segfault. Actualy, I can debug it anyway, just continuing execution. If I press enter the signal handler finishes, returns to the place where it was generated (main function), and the problem is not solved, but this time gdb is there to catch it. But I'd like to now how does it really works.
If I use the same method in gnu/linux I can see what I want to see here:
#5 0x00007f6809bf349e in std::istream::get() () from /usr/lib64/libstdc++.so.6
#6 0x00000000004008cd in my_signal_handler () at /home/zaskar/.zinjai/sin_titulo.cpp:6
#7 <signal handler called>
#8 0x00000000004008f9 in main (argc=1, argv=0x7fffa0613108) at /home/zaskar/.zinjai/sin_titulo.cpp:11
So the question is, why gdb cannot show me the correct backtrace from withing the signal handler? Or what am I doing wrong? Is there any better way to solve it?

Gdk::Pixmap is giving me a segmentation fault on create()

I am doing pixel drawing onto a Gtk::DrawingArea. Sometimes an expose event occurs and I need to redraw everything. But drawing every pixel again is slow, so I'm trying to create a Sdk::Pixmap and draw to it, then draw it to the screen when needed.
I'm trying to create a Sdk::Pixmap and draw to it with draw_point(). Here is my code:
In the hpp:
Glib::RefPtr<Gdk::Pixmap>pixmap;
Glib::RefPtr<Gdk::GC>pixGC;
In the cpp:
Glib::RefPtr<Gdk::Drawable> d = Gdk::Drawable::create(); // this has a value of 1
pixmap = Gdk::Pixmap::create(d, width, height, 3); // this call is giving me a seg fault
pixGC = Gdk::GC::create();
And when drawing:
pixmap->draw_point(pixGC,x, y); // don't even know if this works yet because of the seg fault
What's wrong with my code? :(
Also, I haven't written the code to draw to the actual DrawingArea yet.
Edit: Ok I fixed the first seg fault with:
pixmap = Gdk::Pixmap::create(get_window(), width, height, 3);
pixGC = Gdk::GC::create(get_window());
Thanks to this link:
http://marc.info/?l=gtkmm&m=108547746915009
But now I get this:
The program 'programName' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 69525 error_code 9 request_code 64 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Stack trace:
Breakpoint 3, 0x00007ffff72830e0 in _XError ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0 0x00007ffff72830e0 in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#1 0x00007ffff72801d1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff7280215 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff7281050 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff727c99d in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff727ca2b in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff725f954 in XCreatePixmap ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007ffff3e2f48d in ?? ()
from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#8 0x00007ffff6de048d in Gdk::Pixmap::Pixmap (this=0x7fffd4000930,
drawable=..., width=256, height=256, depth=3, __in_chrg=<optimized out>,
__vtt_parm=<optimized out>) at pixmap.cc:55
#9 0x00007ffff6de0d71 in Gdk::Pixmap::create (drawable=..., width=256,
height=256, depth=<optimized out>) at pixmap.cc:317
#10 0x00000000004408e1 in Viewer::start (this=0x7fffffffea00, width=256,
height=256) at viewer.cpp:23
#11 0x000000000042e380 in AppWindow::rayTraceDrawer (this=0x7fffffffe8e0)
at appwindow.cpp:25
#12 0x0000000000432cd8 in std::_Mem_fn<void (AppWindow::*)()>::operator() (
this=0x767b58, __object=0x7fffffffe8e0)
at /usr/include/c++/4.6/functional:551
#13 0x0000000000432b8b in std::_Bind_result<void, std::_Mem_fn<void (AppWindow::---Type <return> to continue, or q <return> to quit---
*)()> (AppWindow*)>::__call<void, , 0>(std::tuple<>&&, std::_Index_tuple<0>, std::_Bind_result<void, std::_Mem_fn<void (AppWindow::*)()> (AppWindow*)>::__enable_if_void<void>::type) (this=0x767b58, __args=...)
at /usr/include/c++/4.6/functional:1287
#14 0x0000000000432ae3 in std::_Bind_result<void, std::_Mem_fn<void (AppWindow::*)()> (AppWindow*)>::operator()<>() (this=0x767b58)
at /usr/include/c++/4.6/functional:1378
#15 0x0000000000432972 in std::thread::_Impl<std::_Bind_result<void, std::_Mem_fn<void (AppWindow::*)()> (AppWindow*)> >::_M_run() (this=0x767b40)
at /usr/include/c++/4.6/thread:117
#16 0x00007ffff6031c78 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#17 0x00007ffff589de9a in start_thread ()
from /lib/x86_64-linux-gnu/libpthread.so.0
#18 0x00007ffff55ca3fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#19 0x0000000000000000 in ?? ()
Is this because I'm creating the pixmap on a background thread?
Edit 2:
Nope, moved to UI thread and still crashing...
Edit 3:
Looks like I may have fixed it. The problem was accessing get_window() too early. Moved code to on_realize and it stopped crashing. Not sure if pixmap is valid yet though...will post after I figure out how to draw from pixmap to drawingarea.
And the solution after so many hours is:
In on_realize of your DrawingArea:
pixmap = Gdk::Pixmap::create(get_window(), width, height, get_window()->get_depth());
pixGC = Gdk::GC::create(get_window());
Draw to pixmap:
pixGC->set_foreground(color);
pixmap->draw_point(pixGC,x,y);
Then to draw to DrawingArea:
get_window()->draw_drawable(get_style()->get_fg_gc(get_state()),
pixmap,
0,0,0,0);

GDB: stepping into a library

Runnning my application I get a Segmentation fault. I ran gdb to check where my code was failing but I get the following output:
Program received signal SIGSEGV, Segmentation fault.
0x39ca8000 in ?? ()
(gdb) bt
#0 0x39ca8000 in ?? ()
#1 0xb7d5df9a in sc_core::sc_port_base::complete_binding() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#2 0xb7d5e104 in sc_core::sc_port_registry::complete_binding() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#3 0xb7d5e13e in sc_core::sc_port_registry::elaboration_done() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#4 0xb7dc669d in sc_core::sc_simcontext::elaborate() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#5 0xb7dc8567 in sc_core::sc_simcontext::initialize(bool) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#6 0xb7dc8b19 in sc_core::sc_simcontext::simulate(sc_core::sc_time const&) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#7 0xb7dc9708 in sc_core::sc_start(sc_core::sc_time const&) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#8 0x080555a8 in sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
#9 0x08055119 in sc_main (argc=1, argv=0xbffff524) at module_pfn.cpp:49
#10 0xb7dbc698 in sc_elab_and_sim () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#11 0xb7d522e7 in main () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#12 0xb7a2e4d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#13 0x08054da1 in _start ()
As you can see, everything comes from a library, except the 'main' call and 'start',where I set breakpoints, but they fail immediately there. I mean:
#8 0x080555a8 in sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
#9 0x08055119 in sc_main (argc=1, argv=0xbffff524) at module_pfn.cpp:49
...
(gdb) br /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
Breakpoint 2 at 0x8055584: file /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h, line 608.
(gdb) r
Starting program: /home/guest/Solutions/eln/systemc-ams/module_pfn
...
Breakpoint 2, sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
608 sc_start( sc_time( duration, time_unit ) );
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x39ca8000 in ?? ()
And we go back to the start.
I am not able to understand where this is failing. I see there is the name of the place in which this is failing: sc_core::sc_port_base::complete_binding() and I have access to the cpp where this function can be found, but only in the source files (not the library). The problem is that I would really like to go step by step through that code, is it possible?
Thanks :)
Thanks guys!
I used a library with debug info and now I can go through the library code.

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

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 :)
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.