Access Violations on al_load_bitmap()

Allegro 5.1.13 - Windows 7+

I'm getting intermittent access violations (mostly on mobile hardware) when loading a bitmap.

I'm assuming that I'm actually writing into program memory with a bad array index or something because its only intermittent and seems to show up more often when I have a lot of other audio and graphics data loading. But I'm scouring my code for this bug and I'm not coming up with anything.

(EDIT:) the crash seems to be occurring in an internal allegro call to _al_save_png_f even though I'm loading an image, not saving one. I'm guessing its internally loading the bitmap and then saving it to a native state but I can't see what part of it is failing...

Calls Stack: al_load_bitmap() -> _al_load_bitmap() -> _al_load_bitmap_flags() -> __al_load_png() -> __al_load_png_f() -> __al_save_png_f()

I'm using VS 2015 Community Edition and got the packages from NuGet - is there some way for me to see the line of code that its failing on?

It would be nice for me to be able to TRAP these errors instead of having them hard crash...


Allegro definitely doesn't call _al_save_png_f inside _al_load_png_f. If that's your call stack, something's seriously wrong. Can you reproduce this with the debug Allegro library?


Absolutely. In fact it seems to happen more often (if not exclusively) in debug.

Also seems to happen regardless of DX or OpenGL implementation which surprised me.


Maybe you should try running a memchecker? I've only used valgrind under Linux.


DrMemory just bogs down the system and eventually stops... I have no clue.


Maybe wait longer / retry several times? These tools slow down everything considerably.
Apart from carefully placing asserts all over your code, I've got no further idea, sorry.


But its safe to say that program memory is being overwritten if that callstack is impossible, yes?


Guess so. Another possibility would be a corrupted build: I guess you've already tried a clean rebuild? Could maybe have something to do with mixing versions of libraries or binaries/headers or something like that? Allegro checks for the latter, though.

Chris Katko

I second Valgrind. It's an industry known and maintained tool and it slows things down but not THAT MUCH.

I managed to load the Dolphin gamecube emulator on Valgrind. Yeah, it was slow. But it still worked. The point being, if I can manage Dolphin which needs a ~>3 GHZ processor to run, you should be able to run your game (with much less slow down).

Load your program with Valgrind, and walk away for a couple hours (or minutes). If necessary, at some fake user input into your program so that it engages enemies, and comment out any checks that would "end" the game so it just keeps running (even if you end up with negative score or whatever). The point there is, keep the game running until it crashes, so you don't have to be the one to physically be there and the the "patience game" waiting for your slower-than-usual game to finally trigger.

If you've got a memory leak that eventually kills Allegro/whatever, it'll show that leak as it happens.


corrupted build / version mismatch

That's the other route I'd definitely check (though Valgrind will show errors in library code too!). Because it really sounds like an error "that should never happen" so something is clearly broken somewhere. Perhaps I worded that poorly, but I mean to say, it's certainly not your typical scenario for a crash.

I'd definite do a CLEAN re-install of all Allegro libraries and even try a different version of Allegro in the case that the specific binary's shipped with NuGET were corrupted or something. (Which I've never heard of happening before but... heck, anything is possible.)

... There's no weird chance of a 32 verses 64-bit library/header mismatch, is there?

Another option is compiling the newest github version from scratch to ensure everything is built from exactly the same, non-mismatched, source code/headers/etc.


I'm trying to go to Allegro via nuGet to see if this is an allegro issue thats been patched...

But seems to change something with OpenGL defines because no matter what I do, I can't seem to get the build to realize that the extensions are there.

ie: GL_TEXTURE1' : undeclared identifier.
'glActiveTexture' ...
'glGetUniformLocation' ...

This wasn't a problem with 5.1.13.

I've tried defining GL_GLEXT_PROTOTYPES before allegro library includes, I've tried including gl.h and gext.h separately and made sure the define was in place before either of those.

How do you migrate an openGL project from 5.1.13 to ?
What GL related stuff was removed that I now have to reference on my own? And How do I do it?

FIX: #define ALLEGRO_UNSTABLE before allegro libs?

Shrug. Seems to allow me to build anyway.
Doesn't fix the memory issue but shrug.


So does this happen with any PNG file you try? Have you tried reducing the amount of code you have (e.g. does loading the file straight from your main function work?).


It seems to only happen in one particular object at this point, so I'm looking into WHY that is.

It didn't crash in the same place when I was loading BMP's instead of PNGs.
Also, I thought perhaps it was related to libPNG's warning about iCCC? errors about sRGB profiles? which is why I tried bitmaps and thought it was odd that there seemed to be different behaviours.

my laptop has since died. either a bad drive or a bad windows update, its blue screening now. so, a build issue it could have been, or a corrupt file somewhere.

Thus, I have no machine on which this behaviour can be tested even. So debugging just got super super fun :D

Chris Katko
thebignic said:

my laptop has since died. either a bad drive or a bad windows update, its blue screening now. so, a build issue it could have been, or a corrupt file somewhere.

Maybe that's related to a lot of your recent issues...


So debugging just got super super fun :D

Screw it, we'll test it LIVE!

Thread #616832. Printed from