I'm having a strange problem with Visual Studio 2k17 and I'm hoping to find some insight on the matter here.

On Debug it compiles and builds fine. However, on Release it runs into some problems.

Here's a simplified version of my program, contained in an header implementation file.

Now, I have two instances of issues here.

The first instance is setting SPRITE_A's enum to 0. When I do this, al_load_bitmap(...) crashes the program and gives a read access violation.

The second instance is looking at the code above, but this time al_destroy_bitmap(...), at the first iteration of the for loop (index 0), crashes the program, giving another read access violation.

These are the only allegro calls for creating and deleting, nothing else affects variables directly.

Am I experiencing heap corruption or are the allegro functions failing on my part?

You need to learn how enums and arrays work. An array is zero-indexed. That means the first element is at index 0. That means you want your enum to start at 0. Your array is uninitialized. It holds random values until you set them to something sensible like 0. This is why your destruction for loop crashes, because it is trying to destroy nonsense memory addresses.

enum SPRITE_INDEX {
   SPRITE_A = 0,
   SPRITE_B = 1,
   SPRITE_C = 2,
   NUM_SPRITES = 3
};

ALLEGRO_BITMAP* sprites[NUM_SPRITES] = {0};

Is al_destroy_bitmap() not capable of deleting a nullptr value?

I figured initializing the entire array to nullptr would be trivial, but keep it from holding onto garbage before attempting to delete those pointers.

The values in the array are not null. They're undefined. You have to initialize them to zero. Whether al_destroy_bitmap handles null values is not the point.

I'm still running into the issue of al_load_bitmap(...) crashing when SPRITE_A is set to 0.

When I set SPRITE_A to anything above 1, then it no longer crashes and the destruction crash happens.

Initializing sprite_STORAGE[] with '0' has had no effect.

Actually, you did initialize the bitmap_storage array to null. Nevermind that, I didn't see it. However, al_load_bitmap should never crash, only return NULL on failure.

Post an actual example program that crashes and fails and we can see what's wrong.

EDIT: Making 'i' start at 2 (or whatever the first bitmap index is, above 1) instead of 0 in the destruction function seems to fixed the destruction crash.

Still doesn't answer the question of why it crashes when loading at index 0.

Something else is going on. Neither one of those functions should be crashing. Have you compiled in debug mode and looked at allegro.log?

I've managed to get past the al_load_bitmap() function error. Small mistake with directories.

However, another issue has showed up. This time with al_clone_bitmap(), which attempts to clone a bitmap from the array shown. Crashes with a read access violation error upon attempting to clone the first indexed bitmap, even though al_load_bitmap did not return NULL.

Again, the strange thing about this is this only appears to be a problem if I assign the first indexed bitmap below an index of 1. If I set the first loaded bitmap's index above 1, then everything works as intended.

I'm not entirely sure how to read the allegro log file, should I include it?

EDIT: Further testing shows that this error is actually inconsistent. Sometimes it builds, sometimes it doesn't. But when it does build, the first indexed bitmap didn't properly load, and shows as an empty bitmap (No image). Any others loaded afterward are fine though.

When I try to exit the program the destruction error happens again, with the first indexed bitmap.

EDIT 2:

Some debug info...

Debug Build:
https://i.gyazo.com/thumb/1200/97152037910034f5c72c325787967a43-png.jpg

Release Build: WITH FIRST INDEX SET TO 1...
https://i.gyazo.com/thumb/1200/e3370b2db7aa1c58c24a29599a040f59-png.jpg

Release Build: WITH FIRST INDEX SET TO 2...
https://i.gyazo.com/thumb/1200/956ed6fe576af79be764d6c80077bcbb-png.jpg

Something is affecting the first two indexes of this array in Release build.

This shouldn't even run.

void destroyBitmaps() {
   for (int i = 0; i < 0; i++) {
      std::cout << i << "\t" << bitmaps_SPRITES[i] << std::endl; // CRASHES AT ITERATION 0.
      al_destroy_bitmap(bitmaps_SPRITES[i]);
}
}

Try to make a minimal example that does the same thing. I don't have all your resources so I can't test your example.

Not sure how that got in but thats a typo, its iterating over the entire array. 0 should be MAX_BITMAPS.

However I've solved the issue somehow.

I was loading bitmaps in another file and for some reason, al_load_bitmap(...) was corrupting the pointers in the bitmap storage array in this file indirectly. Still strange since even though I was loading much more than just 2 bitmaps in the separate file, it only affected the first two indexes of the bitmap storage array in this file. And that this was only happening in the Release build.

Loading the bitmaps in the separate file before the ones in this one has fixed my issue on all accounts. The only cause I can come up with is my messy ordering of header files.

EDIT:

Here is the separate file. The original file includes this one.

One thing. You're declaring Fonts before Total_Fonts is named in the enum.

Another, you're not declaring the Fonts array as extern and defining it inside another module. That could give you problems.