12 bytes Memleak when deleting a *wxBitmap() ?

[dib]

I need some help with that - whenever I exit the program I get a memleak of 12 bytes per loaded bitmap (I am running in debug mode)

Definition of a structure for my bitmaps:

typedef struct
{
float x1; // x-coordinate
float y1; // y-coordinate
float width;
float height;
wxBitmap *bitm; // Bitmap
}
G_A_Structure_Bitmap;

typedef G_A_Structure_Bitmap *G_A_Pointer_Bitmap;


G_Bitmap = new G_A_Pointer_Bitmap[1000]; // DeInit


I then create a new struct for later use and assign it a bitmap with a loadfile:

G_Bitmap = new G_A_Structure_Bitmap; // DeInit

G_Bitmap->x1 = 0.0;
G_Bitmap->y1 = 0.0;
G_Bitmap->x2 = 0.0;
G_Bitmap->y2 = 0.0;

wxImage L_Image;
L_Image.LoadFile( s, wxBITMAP_TYPE_ANY);

G_Bitmap->bitm = new wxBitmap (L_Image);

L_Image.Destroy();


So far so good - it seems to be working OK until here -

But after I am done with the program I try to clean up and have 12 bytes memleak left over for every bitmap I previously loaded:

for (i=0; i<G_D_Number_Bitmaps_created; i++)
{
delete G_Bitmap->bitm;
G_Bitmap->bitm = NULL;
}

delete[] G_Bitmap;

Can please someone push me in the right direction? I am totally clueless as it worked in 1.68 and not even trial-and-error programming works her anymore

This code worked before with wxwidgets 1.68 (whoops, I guess I am getting old - he he he)

I am running VC6, wxwidgets 2.6.1

Thanks in advance,
Joerg

[ssigala]

Perhaps you should also deallocate the structure for each bitmap:

Code: Select all

	for (i=0; i<G_D_Number_Bitmaps_created; i++) 
  	{
             delete G_Bitmap[i]->bitm;
             G_Bitmap[i]->bitm = NULL;
             delete g_Bitmap[i];                <------ here
             g_Bitmap[i] = NULL;
  	}	   
  	
  	delete[] G_Bitmap;

[dib]

Perhaps you should also deallocate the structure for each bitmap:

Code: Select all

...
             delete g_Bitmap[i];                <------ here
...

Thanks for the suggestion. unfortunately that did not help either.
I will keep on trying...

[leio]

What tells you that you have a memleak in the first place? Can't that tool tell you also where does the memleak happen?
I know of tools that report memleaks correctly and are able to identify the location of the memory allocation that isn't deallocated. And I've heard of tools that can't identify the location, but are very capable of reporting memory leaks falsely - cases where it thinks are leaks, but really aren't.

[dib]

I am using MS Dev VC 6 and an older version of BoundsChecker on Win XP.
When I use BC I can trace it down to wxBitmap::CreateFromImage (52 bytes) to wxDIB::CovertToBitmap(). (Resource leak)

I agree with you that it might be a false report - maybe it is the older version of BC and I should just upgrade...

But Microsofts own (internal) debugger also reports a memleak (12 bytes) - so I am somewhat curious.

Joerg

What tells you that you have a memleak in the first place? Can't that tool tell you also where does the memleak happen?
I know of tools that report memleaks correctly and are able to identify the location of the memory allocation that isn't deallocated. And I've heard of tools that can't identify the location, but are very capable of reporting memory leaks falsely - cases where it thinks are leaks, but really aren't.

[Jorg]

Any reason for not using arrays and classes ? It is easier in the initialisation, and maybe the mem management and the "false leak" report also improved.

Regards,
- Jorgen

[dib]

Jorgen,

Well, I have a reason - the application is up and running since 1995 and I just recently (finally!) ported from wx 1.68 to wx2.6.1 - I am eager to push out the program and did not have too much time looking into changing the old structures and sources especially because of backwards compatibility.
But I will try and see where I can get it from there - you probably know how it works: it is a constant battle with time.

Regards,
Joerg

Any reason for not using arrays and classes ? It is easier in the initialisation, and maybe the mem management and the "false leak" report also improved.

Regards,
- Jorgen