MFC HBITMAP memory leak does not go away

Question

whenever I execute the below code, my memory in task manager for the application keeps on increasing endlessly. I found similiar questions here on stackoverflow and I did some DeleteObject calls like they stated but this still did not solve the ever increasing memory when this code executes.

How can this be solved? What am I doing wrong?

SetControlPicture(const UINT ID_PICTURE_CONTROL)
{
CImage image;
CBitmap bitmap;
HRESULT hresult;    
CStatic* pItem = (CStatic*)GetDlgItem(ID_PICTURE_CONTROL);

hresult = image.Load(_T("./Data/Images/RED_ON.png")); 
                if(hresult != E_FAIL)
                {
                    HBITMAP hBitMap = image.Detach();
                    bitmap.Attach(hBitMap);
                    HBITMAP hBitMapPrev =  pItem->SetBitmap(bitmap);        
                    if (hBitMapPrev)
                    {
                        DeleteObject(hBitMapPrev); // *** do not forget to delete the previously associated bitmap
                    }
                 DeleteObject(hBitMap); 
                }
}

how have you checked that it is exactly the code which causes memory issues? — varnie, Sep 27 '13 at 12:39
Task Manager is not a memory profiler and it is utterly incapable of doing that job. It can however do a better job with the leak that you are actually fretting about. View + Select Columns and tick GDI Objects. — Hans Passant, Sep 27 '13 at 12:43
@varnie This function is called whenever the selected index of a combo box is changed. So what I did was scroll up and down repeatedly through the combo box entries selecting a different one every time, while monitoring the task managers memory usage. I noticed a direct relation between the memory spiking upwards (and staying there) and me scrolling/selecting different indexes in the combo box. Another thing I want to point is that I completely commented the above function and repeated the process above and found that the memory did not increase all the time then. :/ — skyzaDev, Sep 27 '13 at 19:05
@HansPassant I do have GDI objects column enabled in my task manager and I remember seeing that it remained stable at around 107-110 although the memory usage kept increasing? I am thinking that I somehow am not deleting all the objects or not deleting them correctly/at the right times? — skyzaDev, Sep 27 '13 at 19:06
As I said, strong indication that you don't actually have a leak. Just write test code, put a loop around this code and execute it a million times. With the expected behavior that you see memory usage bounce up and down but never grow out of control to bomb the code. — Hans Passant, Sep 27 '13 at 20:29

score 0 · Answer 1 · answered Sep 27 '13 at 15:45

0

AFAIK According to the documentation this must leak. Since Common Control ver. 6.0 you are repsonsible to delete the Bitmap. It is not enough to delete the Bitmap that was returned.

http://msdn.microsoft.com/en-us/library/windows/desktop/bb760782(v=vs.85).aspx

In version 6 of the Microsoft Win32 controls, a bitmap passed to a static control using the STM_SETIMAGE message was the same bitmap returned by a subsequent STM_SETIMAGE message. The client is responsible to delete any bitmap sent to a static control.

answered Sep 27 '13 at 15:45

xMRi

14,982
3
26
59

I think you are right yes, that is why I added the DeleteObject() calls in the function above, but with no success. My problem is however... how do I code to stop this leak and stop my memory from ever increasing? – skyzaDev Sep 27 '13 at 19:08
1

Using your code I can not create any GDI leaks. The code is still wrong, because you delete an Object that is still in use. – xMRi Sep 30 '13 at 06:40

MFC HBITMAP memory leak does not go away

1 Answers1