Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu Exchange / Crash in Image class for Release Only
- By jblovloss Date 2009-11-23 05:24 Edited 2009-11-26 07:47
There's a strange bug that I haven't quite been able to track, even after searching through the source code of Gosu itself. It's strange because it only occurs in release mode. What essentially happens is that whenever I try to load a png image in, I do so through my own class called a GlowImage (gosu low-level) which simply keeps both the bmp and image pointers and makes sure they stay matched... that way I can edit the image directly any time I want. I found it hard to deal with the static Gosu Image so this was my way around it.

Well, that's all well and good, except it crashes in release mode.

Granted, this seems like an odd enough pipeline to introduce some bugs, but having run through it step by step, I don't see how. Here's how the process goes:

1. Some setup stuff happens for my Application class. It goes to load media

2. I load my images into a table of enums that I use to organize my media. ( bwk_set is a macro for a data manager class )

    bwk_set(  BwkSlots::BWK_IMG_LOGO,       _loadImage( L"logo.png" ));

3. Inside the _loadImage function, we see this:

   GlowImage * BwkApplication::_loadImage( std::wstring file ) {
       return new GlowImage(graphics(), L".\\resources\\images\\" + file );
   }

4. So far so good... I think. So next, in GlowImage's appropriate constructor, we see that it simply NULLs some variables and then leaps down to my "loadFromFile" function.

5. Here's the loadFromFile function, where gfx is a (&) reference to the graphics class of the main application:

    // Delete the previous image and bitmap, if they exist
    if( _img ) {
        delete _img;
    }
    if( _bmp ) {
        delete _bmp;
    }

    // Create a new image and bitmap using the supplied filename
    _bmp = new Gosu::Bitmap(Gosu::quickLoadBitmap(fileName));
    _img = new Gosu::Image(_gfx, *_bmp, true);

! The EXACT place of the crash is Gosu::Image::setPixel !

Any ideas?

***************************************************************************************************
FIXED

Sort of.

I removed my "GlowImage" crud and just used Images straight. I still wish you could go from an Image to a Bitmap, but at least everything works really nice. I probably confused auto pointers by doing all that pointer logic.
- By jlnr (dev) Date 2009-11-23 18:03
Phew, no idea… actually setPixel is pretty harmless, so that's a surprise. :) Definitely sounds like memory corruption occurs earlier somewhere. Did you try slimming the program down to the minimum of what you illustrated, and seeing if it works then?

Also, I think the behavior of uninitialized variables may well be different between Release and Debug. Did you double-check all of those? (I don't trust pointers unless they're from boost too. ;) )
- By jblovloss Date 2009-11-25 04:01 Edited 2009-11-25 04:09
Alright, so the crash only occurs when I have tileable set to true. It needs to be set to true or the levels look reeeeeally odd, but if i set them all to false, it runs. This is not an issue in debug mode. I'll continue investigating it, but there you go.

__EDIT__

I found a hack, lol. Since I have my own wrapper image class, i just made draw stretch the image a bit and draw with an offset so the border is chopped off ;)

I may have done something funny which caused the existence of borders to crash in the first place, I dunno. I can email you the source code if you like, jlnr, it's going to be FOSS anyway, I just need it to stay private since its still a wet painting until I'm finished.
- By jblovloss Date 2009-11-26 06:06
Little update. The problem is somewhere in Gosu::Graphics::createImage. It only happens when i set hard borders. For my big images I get some type of crash with setpixel. This I have gathered from the code to happen inside a particular statement scope:

__Graphics.cpp___
    if ((borderFlags & bfTileable) == bfTileable &&
        srcWidth == srcHeight &&
        (srcWidth & (srcWidth - 1)) == 0 &&
        srcWidth >= 64)
    { ... }
________________

My 50x50 tiles clearly dont fit so I wanna fix those first. Less code to worry about. Those dont crash on setPixel! They crash on... who knows? It's a weird stack error and the call stack is basically an explosive jumble of "omg dlls!"

  I have -NO- idea if this is met:     if (srcWidth > maxSize - 2 || srcHeight > maxSize - 2)    50x50 seems too small to hit that. In fact it looks more like 1000+ x 1000+ from the Texture implementation. So lets say thats not hit either.

*sigh* I suspect it has something to do with pointers. I'm going to try keeping a boost pointer to the bitmap and image instead of normal pointers - there may be some confusion in there. I wonder what happens different in release regarding that
- By mathias Date 2009-11-27 12:22
I too had problems with weird crashes in the release build with MSVS. Most of the time I forgot to initialize a variable or did something stupid with points that the debug build just ignores. I guess you have the same problem with your code.
Up Topic Gosu / Gosu Exchange / Crash in Image class for Release Only

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill