10 replies to this topic

[Plethora]

I'm posting this with some reluctance, as I prefer to figure out these sorts of errors myself, but I'm lost and could use the help.  I recently ported my project from Code::Blocks to MS VS 2010 express.  Things mostly went fine, and after a little bit of work I have my program running just as it did before, except it crashes on exit.

 

The debugger dumps me into a file called crtexe.c, which is a windows file that handles launching (and/or terminating) a program, as far as I can tell based on google results anyway.  I get a message saying I have an unhandled exception at 0x76ff15de (ntdll.dll).

 

Now google searching this topic has shown me that this problem is likely the result of a null pointer hanging out somewhere.  The problem I'm having is that nothing I'm getting back from the debugger is even remotely helpful in tracking it down. As far as I can tell, main() actually does return successfully, which doesn't make sense to my noob brain so maybe I'm wrong.  

 

Anyway, if there is anyone out there who can give me a hint on how I might solve this, I'd be very appreciative.

[Ectara]

Try removing functionality from the program one at a time, until the error stops occurring on exit.

[Endurion]

Usually a exception comes with a bit more of info (show all you've got). Is the debugger stopping in the c runtime? If so, there should be a comment or message near the break location indicating what went wrong.

 

Probably you accessed freed memory or wrote out of bounds somewhere.

[Plethora]

I've been working my way through my program as you've suggested Ectara, so far no luck, but I'll keep at it.  In the mean time...

 

In addition to unhandled exception I get "Access violation reading location 0x000000008".  It dumps me in the c runtime (that's crtexe.c I'm assuming).  This is the code at the break:

 

        __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) )
        {
            /*
             * Should never reach here
             */

            mainret = GetExceptionCode();

            /*
             * Note that if the exe is managed app, we don't really need to
             * call exit or _c_exit. .cctor should be able to take care of
             * this.
             */
            if ( !managedapp )
                _exit(mainret);

            if (has_cctor == 0)
                _cexit();
        } /* end of try - except */

[Ectara]

Small offsets from 0 often imply that the application attempted to access the member of a null instance of a class/struct.

Can you point out the exact line in that block where the debugger breaks in?

Edited by Ectara, 24 February 2013 - 01:48 PM.

[Plethora]

Progress!

 

Ok so I've isolated where the problem occurs just by systematically disabling things (thanks ectara, for your earlier suggestion).  I still have a bit of a problem though, as I think I'm failing to understand how something works but I'm not sure what the problem is precisely.  This is going to be SFML specific to some degree unfortunately.  The error occurs as a result of this method:

 

sf::Sprite Menu_Graphics::createTextButton(sf::Sprite buttonSprite, std::string buttonText)
{
    sf::IntRect subRect = buttonSprite.getTextureRect();
    button.create(subRect.width, subRect.height);
    button.clear(sf::Color(255, 255, 255, 0));

    text.setString(buttonText);
    text.setFont(menuFonts[0]);
    text.setColor(sf::Color::Red);
    text.setCharacterSize(20);
    text.setPosition(25, 8);

    button.draw(buttonSprite);
    button.draw(text);
    button.display();

    sf::Sprite toReturn(button.getTexture());
    return toReturn;
}

 

And, in particular, its an issue with the text object, which is an object of class sf::Text (as in, when I remove text from the method, no more error).  Now what I think is relevant is that sf::Text is dependent on sf::Font objects (in this case, the object accessed as menuFonts[0].  A Font object must remain persistent as long as it is being used by a Text object.  I get that just fine, and as my program functions as intended prior to closing then the Font must exist until then.  

 

So this method in particular takes an sf::Sprite and an std::String and returns a sprite with text on it.  This method returns in a method that puts together the entirety of the Menu for my game, within the class Menu_Graphics.  Now, the fonts all exist in a vector (menuFonts) which is a data member of this class.  However, the put together menu, with all its various components, is eventually passed to my programs main Graphics class.  Obviously menuFonts is out of scope once my menu is passed out of the class.  Is it possible this is the problem?

[bollµ]

Just shooting in the dark here, but this happened to me when a library I was using was not built using the Unicode font set, while my game used the Unicode font set. It too would go and crash in a string related part of my library that was actually perfectly alright. Do try and recompile the library you are using so that both the main program as well as the library are using the same font set.

 

Hope this helps!

~Bollu

Edited by bollµ, 25 February 2013 - 05:48 AM.

[Dragonsoulj]

While bollu's idea could be true, are you also making sure your resources are all loaded? In particular is your font loading? I know SFML gives an example for exiting if your resource doesn't load, try using that if you are not.

[Adam_42]

It could be a destruction order issue if you have any non-POD global or static objects. It's usually best to heap allocate them so you get control of the destruction order.

 

What's the full call stack at the time of the crash?

[SymLinked]

I'm going with Adam's guess. Sounds like some static object is destructing and crashing while doing so. I've had that a number of times with third-party libraries.

[Plethora]

Thought I'd add this post in case anyone comes across this thread in the future.  I didn't solve my problem as such but I do have more info on it, I just decided I'd go another way with my design as I didn't want to devote any more time to tracking this down.

 

As I said, the problem started when I ported my project to VS2010 Express.  I had done all previous coding with Code::Blocks and the exact code that produced the crash did not do so in Code::Blocks.

 

Linking the SFML libraries statically also solved the problem.  It's more a workaround than a solution, but that could help pinpoint it if one were so inclined.

 

In searching for a solution, I came across a few mentions of a crash on exit also related to sf::font in the SFML forums.  It apparently involved, as Adam and Sym surmised, a problem with the destruction order of certain items.  This did not lead to a solution though, and I want to be clear and say that I don't know nearly enough about SFML or C++ in general to say if my error was the same as the one I'm citing.  It's still entirely possible I was just messing something up on my end (I'd even say it's likely).

 

Anyway, like I said, this info is here for whatever use it can be if anyone in the future comes across this post.  Maybe it'll help, maybe it won't, but its here.