IMG_SavePNG crash on Android

SDL Development
1

Using SDL2 2.0.3 and SDL2_image 2.0.0, I’ve got my game running on Android now. However, I just noticed that my screenshot code crashes the game.

Here’s my entire screenshot function: http://pastebin.com/JFuX8fxs

Here’s the tombstone file: http://pastebin.com/tAjhBeGQ

I noticed this on line 363: “<qgl2DrvAPI_glReadPixels:192>: GL_OUT_OF_MEMORY” Could that have something to do with it? Any ideas?

2

Oh, I wanted to add: If I comment out line 37 in my screenshot function (the call to IMG_SavePNG) it works fine and doesn’t crash, although obviously it also doesn’t do anything useful!
When I do not comment it out, and the game crashes, the result is a 0 byte .png file in the screenshots folder.

3

You’ll probably need to dig in and debug this. I haven’t seen this before,
and I’m not sure what line it’s crashing in.On Fri, Jun 20, 2014 at 3:02 PM, Dark_Oppressor wrote:

Oh, I wanted to add: If I comment out line 37 in my screenshot function
(the call to IMG_SavePNG) it works fine and doesn’t crash, although
obviously it also doesn’t do anything useful!
When I do not comment it out, and the game crashes, the result is a 0 byte
.png file in the screenshots folder.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

I don’t actually know how to debug with my current setup. I tried running DDMS and attaching via both jdb and jswat, which worked, but when the application crashed nothing happened. It’s probably something I setup wrong. Any pointers for debugging an Android app from the command line?

5

You have the function that it crashed in, and an offset into the function.

There is information in README-android.txt on turning that into line
numbers for debugging, and then you can inspect the code to see how it
might crash, and then put in print messages to validate your assumptions.On Sun, Jun 22, 2014 at 1:46 PM, Dark_Oppressor wrote:

I don’t actually know how to debug with my current setup. I tried
running DDMS and attaching via both jdb and jswat, which worked, but when
the application crashed nothing happened. It’s probably something I setup
wrong. Any pointers for debugging an Android app from the command line?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

Here’s my entire screenshot function: http://pastebin.com/JFuX8fxs

Here’s the tombstone file: http://pastebin.com/tAjhBeGQ
Nothing obviously wrong here but there are a few things:

  1. You’re allocating a potentially very large buffer (pixel_data) on
    the stack. This can lead to stack overflow. I don’t know ARM registers
    but it looks like the bad address (60381000) is close to the stack
    pointer (sp 600fa310). Allocate your buffers on the heap. Remember to
    free them.

  2. You’re querying your [rgba]mask from somewhere else even though
    you’ve taken the screenshot with SDL_PIXELFORMAT_ABGR8888. Are you sure
    this is correct?

  3. Compile your code for desktop Linux and use Valgrind or
    AddressSanitizer to debug it. Beware that Valgrind can’t catch stack
    overflows so fix point 1 first. AddressSanitizer is also theoretically
    available on Android but I’ve never tried it and you might have to
    compile also SDL, SDL_image, libng and zlib with it to get meaningful
    results.

I noticed this on line 363: “<qgl2DrvAPI_glReadPixels:192>:
GL_OUT_OF_MEMORY” Could that have something to do with it? Any ideas?
It’s telling you that the screenshot failed because there wasn’t enough
memory. This will probably result in not getting screenshots even if
you can fix the crash. IIRC GL out-of-memory error is special in that
after it has been raised the context might have become invalid so it
should be avoided at all costs.On Fri, 20 Jun 2014 21:59:36 +0000 “Dark_Oppressor” wrote:

7

Sam: That is really cool, thanks! Don’t know how I missed that, it’s a handy tool.

Turo:

  1. Good point! I am allocating pixel_data on the heap now, and the game no longer crashes. It outputs a 1 KB file that is a black rectangle, but that’s better than hard crashing. Like you said in the end of your post, that may be the best I can get. It isn’t even a big deal, as you can take screenshots in Android anyway, I just don’t like having icky stuff like this, and I hate to fix it by “#ifdef GAME_OS_ANDROID AHHH DON’T DO IT #endif”. Anyway, this may invalidate everything else I say, but I have never fully understood the difference between the stack and the heap… Um, so I read up on that after reading your post. Wow. I’m not sure how I got this far without knowing about that.

  2. That rgba mask is coming from here:

Code:
void Engine_Interface::get_rgba_masks(uint32_t* rmask,uint32_t* gmask,uint32_t* bmask,uint32_t* amask){
if(SDL_BYTEORDER==SDL_BIG_ENDIAN){
*rmask=0xff000000;
*gmask=0x00ff0000;
*bmask=0x0000ff00;
*amask=0x000000ff;
}
else{
*rmask=0x000000ff;
*gmask=0x0000ff00;
*bmask=0x00ff0000;
*amask=0xff000000;
}
}

As far as I understand, that should be good. I know that it works on Windows, Linux, and OS X.

  1. OK, I will try out Valgrind tonight. I seem to recall using it once years ago.