Jump to content
  • Advertisement
Sign in to follow this  
DeadXorAlive

Embedded object causes segfault with SDL

This topic is 4810 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I had some nasty segfaults (whatever they are) with SDL. After debugging and playing around I sort of find out the reason. It was because the constructor of an embedded object was calling an SDL_image function, it seems before SDL_Init was called. I'd like to initialize SDL either in a member routine of the class that owns that object, or in its constructor. (see code below). So my question is, which constructors get called in what order when you embed an object? (How) is it possible to initialize SDL in say class A, which has an object of class B where the constructor of B calls SDL_image functions?
class Game
{
    public:
    Game() {SDL_Init(SDL_INIT_VIDEO);}  //Not real code of course, just an example
    private:
    Block CurrentBlock;                 //Embedded evil object, yes it's tetris.
};

class Block
{
    public:
    Block() {Square = IMG_Load("images\\SomeImage.png");} //Causes a segfault, I think.
    private:
    SDL_Surface* Square;
};

Share this post


Link to post
Share on other sites
Advertisement
That's very strange, since in C++ constructors of parent objectes (that contain other objects) are called before constructors of those embedded ones. So, the example you provided should run with no problems. Could you put fprintf(stderr, "Called from function: (insert function name)"); in constructors of Game and Block and see what stderr.txt will contain? IMHO the problem lies somewhere else...

Share this post


Link to post
Share on other sites
That's weird. I'm quite sure that when I remove the IMG_Load() call the whole thing just works. Also when I didn't embed the object, but just created an instance in a member function it worked too.
I'm trying and figuring out that fprintf stuff now. Looks useful.

Share this post


Link to post
Share on other sites
your block is a member of Game. When an object is constructed, the constructors of the member objects are called first.So Block constructor is called before SDL is initialized.you should call SDL_Init at the begining of your main() function, or replace CurrentBlock by a pointer to block.

If you load your image in the constructor of Block, you will load it each time you create a block. it would be better to load it once, and put it where you can find it.

I hope this will help you.

Share this post


Link to post
Share on other sites
fprintf(stderr, "call from constructor x") gives in stderr.txt only the call from the embedded class. So that seems to be constructed first. Maybe it's because I have #include "Block.h" in Game.h? It doesn't make sense.

Maybe I just screwed up somehow. The debugger (using the one with DEV-CPP) gives output like: "Error: dll starting at 0xa31000 not found", "Segmentation-fault" and "No symbol 'include' in current context". There's a whole bunch of other output, but I just can't make any sense out of it, sadly.

EDIT: Thanx DrakeSlayer, that helped. It seems I've got to make some adjustments to where I load my surfaces now...

Share this post


Link to post
Share on other sites
Ooops, sorry man, that was stupid mistake from my side. I wasn't sure what was the order of constructors call, so I opened book and read about order of destructors call [embarrass] of course that was unintentional, I thought that I was reading definition for constructors :-/ shit, I should be more careful next time I want to help someone.

Share this post


Link to post
Share on other sites
Don't worry, my mind is all clear now. You still got me finally using this fprintf stuff which I have not been doing. That is very handy indeed. I just fixed a bug that involved doing something in the wrong scope thanx to fprintf(). Big timesaver for a newbie like me who is constantly chasing bugs.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!