Alright, I haven't been using Allegro for a while but this is just plain weird. I've been commenting almost everything out and even this bare bones code crashes:
I know that code alone looks pointless, it's just that I removed all irrelevant code that isn't causing a crash. When I run it it only goes up to pixel 508 and crashes. If I comment out al_map_rgb it goes through just fine. What am I doing wrong?
In the real code, if I just take out al_map_rgb out of the loop and assign it to c, then feed al_put_pixel the color c, it doesn't crash at all.
Using the Allegro 5.0.6 monolith build.
EDIT: Bonus round, modifying directly the ALLEGRO_COLOR paremeters instead of using al_map_rgb causes no crashes. Did I just stumble upon a really obscure bug?
Do you call al_init anywhere?
It's there hidden by an if. Line #32.
Does it crash with al_map_rgb_f and al_get_pixel?
Trying the following code.
#include "allegro5/allegro.h" int main(int argc, char *argv[]) { al_init(); for (int i=0; i<600000; i++) { al_map_rgb_f(1, 1, 1); } return 0; }
With 500000 it works fine, but with 600000 it throws off the 0xC00000FD exception. Same deal with al_map_rgb and al_map_rgb_f.
The same kind of crash also happens with al_get_pixel.
Is it a stack memory error? But I'm not even using it! Unless I have the wrong understanding of it. But it really seems like it since I can just copy paste these loops and it seems to crash eventually. (reducing the maximum limit of each loop ofc)
EDIT: Well it seems like a stack memory error indeed. If I separate the for loop into another function(0 to 100000) and call it several times, it won't crash. What might be the cause of these functions causing this kind of error?
EDIT2: More concrete example of what I mean, if I make my own wrapper function around it:
It doesn't crash with a wrapper.
I tried the first example in your first post, but even with more than 1000x as many iterations it did not crash. I am using 5.04 though. What compiler and compiler version are you using?
Functions that return structs have a bizzare calling convention that differs between compilers (MSVC vs old GCC vs new GCC). Usually you run into this when you're using a different complier to compile your program vs the one that was used to compile the library. So yes... the exact version of your compiler as well as the binary source might be of use.
Yeah I see the problem now, it seems I haven't updated MinGW since 3.4.5 and the monolith builds for that version stopped long ago apparently. I'll update and post back here if I get it working. It seems at the time I didn't care and just got one of the newer Allegro builds anyway.
Sorry for the problem, it's just the first time I run into this sort of error. Thanks for the help.
When this came up last time one idea was to add alternate functions to Allegro 5:
ALLEGRO_COLOR *al_make_rgba_f(ALLEGRO_COLOR *c, float r, float g, float b, float a);
And so on. Instead of returning a struct, this would just returns a pointer and write into the struct. Using it in C/C++ wouldn't be much more difficult:
ALLEGRO_COLOR c; al_draw_line(0, 0, 10, 10, *al_make_rgba_f(&c, 1, 1, 1, 1), 1);
In hindsight it probably was a bad idea having struct parameters at all (i.e. al_draw_line should take a pointer to ALLEGRO_COLOR not a full struct). But nothing we can do about that now.
I've updated to gcc version 4.6.2 and downloaded the MinGW 4.6.2 binaries. Now there's no crash no matter how much I try.
First time I ever come across this sort of problem, I didn't think there would be so much trouble with using clashing versions as it worked fine; so sorry for bringing up a non-existent issue. But maybe it should be pointed out in the manual in any struct-dependent functions, since most guides on the wiki just tend to point people to download the binaries instead.