[A5] Bitmap memory leaks (Release video texture failed)
9inchsamurai

I have been trying to pin down some memory leaks and I've hit a wall where I need to know more about what Allegro is doing/expecting because this isn't making sense to me. I believe I've narrowed the issue down to being alpha channel related.

I tested it on a small piece of bitmap initialization code here:

Globals.ui_sheet = al_load_bitmap(ui_sheet_file);
Globals.cursor_finger = al_create_sub_bitmap(Globals.ui_sheet, 0, 0, 14, 13);
Globals.cursor_arrow_up = al_create_sub_bitmap(Globals.ui_sheet, 0, 70, 11, 7);
Globals.cursor_arrow_right = al_create_sub_bitmap(Globals.ui_sheet, 0, 41, 12, 11);
/* Initialize a bunch more icons here....*/

al_convert_mask_to_alpha(Globals.cursor_finger, COLOR_TRANSPARENCY);
al_convert_mask_to_alpha(Globals.cursor_arrow_up, COLOR_TRANSPARENCY);
al_convert_mask_to_alpha(Globals.cursor_arrow_right, COLOR_TRANSPARENCY);
/* Convert alpha mask for all of them here...*/

al_destroy_bitmap(Globals.ui_sheet);

I've messed around with the timing of the alpha mask function and the delete function, and if I delete the parent bitmap before calling al_convert_mask_to_alpha, then I don't get the log messages saying "Release video texture failed. Release render target failed."

This is what the allegro.log file spits out when I'm initializing most of my bitmaps, and I'm not sure if it means I'm doing something wrong, but the presence of "Alpha doesn't match" also led me to think it's alpha channel related:

d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07354] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07359] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07363] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07367] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07370] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07374] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07377] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07381] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07384] Fake format
d3d      D         d3d_disp.cpp:1174 real_choose_bitmap_format        [   1.07388] Alpha doesn't match
d3d      D         d3d_disp.cpp:1181 real_choose_bitmap_format        [   1.07391] Adapter format is 23
d3d      D         d3d_disp.cpp:1184 real_choose_bitmap_format        [   1.07396] Found a format
d3d      I         d3d_disp.cpp:2283 _al_d3d_create_bitmap            [   1.07399] Chose bitmap format 9
dtor     D               dtor.c:184  _al_register_destructor          [   1.07486] added dtor for object 05AA1FE8, func 0055DC32

I have a last simple question: do I need to call al_destroy_bitmap on bitmaps created from al_create_sub_bitmap? From the documentation it sounded like no, but I just wanted to make sure.

SiegeLord

All bitmaps in principle register their destructor ( al_destroy_bitmap ) in a global list that gets called when Allegro shuts down (after your main function exits). It's possible that this might confuse a memory leak detector, so it's encouraged to destroy them all manually. In the case of sub bitmaps, they also need to be destroyed via al_destroy_bitmap (automatically or manually by you).

Destroying the ui_sheet seems like a very bad idea, as it will invalidate the sub-bitmaps. I'm surprised that it works. The logging statements you see are probably harmless (they are prefixed with 'D' which means debug), they just show how the D3D backend is trying different formats when creating the bitmap.

9inchsamurai
SiegeLord said:

In the case of sub bitmaps, they also need to be destroyed via al_destroy_bitmap (automatically or manually by you).

This could be the cause of my memory leaks because I know I'm creating some sub bitmaps and not retaining pointers to them to be deleted later. I only added al_destroy_bitmap(ui_sheet) as a test there to see what the log would say to me. The documentation for al_create_sub_bitmap made it seem like Allegro would automatically handle memory management when I delete the parent bitmap.

Thomas Fjellstrom

It deletes the parent bitmap and its memory, but not each sub bitmap's structure. Its a low amount of memory per sub bitmap, but they will still leak if you don't free them.

SiegeLord

Right, the documentation for al_create_sub_bitmap refers to the pixel data, but there's still some memory for each sub-bitmap to store things like its width and a pointer back to the parent bitmap, amongst a few other things.

9inchsamurai

It deletes the parent bitmap and its memory, but not each sub bitmap's structure. Its a low amount of memory per sub bitmap, but they will still leak if you don't free them.

Ah okay. Well, I know this is happening every render frame during a specific game state, so that will easily add up over time.

So, do I not need to be worried about the Allegro log telling me

d3d_destroy_bitmap: Release video texture failed.
d3d_destroy_bitmap: Release render target failed.

after I destroy some of these bitmaps?

SiegeLord

Those would probably be indicative of bugs in Allegro, rather than in your code. Just t be clear, what version of it are you using?

9inchsamurai

I'm using 5.0.10.

SiegeLord

5.0.10 is a bit old, and we have fixed a whole bunch of leaks since (not necessarily these though, I haven't checked). There's some MinGW binaries of the newest version towards the end of this thread https://www.allegro.cc/forums/thread/615781/1018005#target if you want to try them (and also MSVC libraries up top as well).

9inchsamurai

Thanks. I haven't updated to 5.1 at all because I don't check the forums for newest versions and just look at the main page. I'll be sure to do that from now on.

Thread #615890. Printed from Allegro.cc