2

Im using C++ and SDL to program a game, and even though I get no errors whenever I try to run it - I get a segmentation fault. I ran the gdb debugger and this is what it gave me when I used the backtrack function : "#0 main () at main.cpp:10" , where the 10th line is the statement right after the try block opens. Can someone tell me what is going on here, Ive never encountered such an error before.

Trista N
  • 403
  • 1
  • 4
  • 11
  • 1
    It's difficult to tell you what's going on, because you haven't posted a [complete test-case](http://sscce.org). – Oliver Charlesworth Mar 20 '12 at 22:02
  • Should I perhaps paste my manager's play function in here? – Trista N Mar 20 '12 at 22:05
  • @K.G - I tried that, its not working. – Trista N Mar 20 '12 at 22:08
  • 1
    If it's less than ~10 lines of code, then yes. If it's not less than ~10 lines, start to simplify it until it *is* that short. You will probably discover the problem in the process. – Oliver Charlesworth Mar 20 '12 at 22:12
  • Could the problem be in the Manager constructor? Does it still segfault if you comment out `play`? – Jesse Vogt Mar 20 '12 at 22:19
  • @Jesse Vogt - Good point, I think. I commented out play and it still gives the segmentation fault. I know there can't be anything wrong with the Manager class, because I used the same code for a previous framework too and it worked fine. – Trista N Mar 20 '12 at 22:24
  • Could you post the Manager default constructor and destructor? – Jesse Vogt Mar 20 '12 at 22:27
  • Use Valgrind to run a debug-enabled (with symbols and non-optimized etc) binary and see the call stack in the Valgrind report. Usually helps to figure out such cases quickly and painlessly. – 0xC0000022L Mar 20 '12 at 22:34
  • This is what I get when I use Valgrind : – Trista N Mar 20 '12 at 22:46
  • Continuation : by 0x403D21: Player::Player(Vector2f, Vector2f, std::string const&, Frame const*) (player.h:7) ==6763== by 0x40322C: Manager::Manager() (manager.cpp:35) ==6763== by 0x402BFB: main (main.cpp:10) ==6763== If you believe this happened as a result of a stack ==6763== overflow in your program's main thread (unlikely but ==6763== possible), you can try to increase the size of the ==6763== main thread stack using the --main-stacksize= flag. ==6763== The main thread stack size used in this run was 8388608. – Trista N Mar 20 '12 at 22:48
  • Does this mean that the root of the problem is at Frame's getWidth() function?? – Trista N Mar 20 '12 at 22:50
  • @JesseVogt - Ive added the constructor and destructor to the main question. – Trista N Mar 20 '12 at 22:56
  • @TristaN: All new information should be in the question, not the comments. Comments can be and are deleted without warning. – Mooing Duck Mar 20 '12 at 23:21
  • Haven't used SDL in years - is Frame part of your framework or is it coming from somewhere else? If it is yours can you post the code? – Jesse Vogt Mar 21 '12 at 04:02
  • 1
    The call to `&frame[0]` in the initializer list for the `player` member looks a bit suspicious since I don't see `frame` initialized - where is that coming from? – Jesse Vogt Mar 21 '12 at 04:11

1 Answers1

1

Maybe you are creating the SDL_Surfaces for bgSurface and fgSurface before calling SDL_Init...

That's why I have the call to SDL_Init in a class constructor, by itself (and SDL_Quit in the constructor). That way you can just make Manager a private subclass of that one:

class Manager : private SDLInitializer
{ /* */  }

And in the constructor:

Manager::Manager() : 
    SDLInitializer(SDL_INIT_VIDEO),
    /* */

And since base classes are initialized before member variables, all goes well!

rodrigo
  • 94,151
  • 12
  • 143
  • 190