STM_SETIMAGE memory leak

[fearless]

Ive been getting back into programming lately and decided to write a small utility that would show the status of streaming movie files being played from my QNAP NAS box down to my PS3 downstairs (just so i know not to turn off the NAS or restart a service or something else if someone is watching stuff downstairs)

I created the app so it would hide in the traybar and created a timer that would launch a thread to get the status of the box and details of any streaming content and change traybar icons and a bitmap image on the main dialog to represent the current status: offline, online (idle), streaming or initializing.




Everything was working fine and i had come near to the end of my project and noticed that the memory usage of my little app whilst running for hours so huge. I decided to investigate.

Spent good few hours re-reading stuff on threads and stacks thinking my memory leak was related to those topics. I used Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653) to view private bytes and could see them increase every time my thread was called (WM_ACTIVATE or via timer or manually via Refresh Button i made)

So i went through my code and refined defined variables, and checked for memory allocations and memory not being freed and commented out code that i thought might lead me to the answer but still had the same issue. After refining code, the private bytes would increase by 64k every time. Over a few hours the memory usage would obviously keep growing and growing. I then decided to preload all icons i use in the app with LoadIcon in a procedure from WM_INITDIALOG and assign the icons to handle variables thinking my constant use of LoadIcon whilst in my thread was the problem.

In the end i tried commenting out:

Invoke SendDlgItemMessage, hWin, IDC_TT_Status,  STM_SETIMAGE, IMAGE_BITMAP, hPngBmp_TT_Init

Im using the png library to load a png and convert it to a bitmap for offline, online, streaming or init, which is done at start of program and assigns the returned bitmaps to handle variables. In my status update thread, the main dialog image is changed to indicate the status by use of the SendDlgItemMessage using STM_SETIMAGE. Commenting out this lead me to discover the memory leak problem did not occur. So looking on MSDN found this for STM_SETIMAGE:

With Windows XP, if the bitmap passed in the STM_SETIMAGE message contains pixels with nonzero alpha, the static control takes a copy of the bitmap. This copied bitmap is returned by the next STM_SETIMAGE message. The client code may independently track the bitmaps passed to the static control, but if it does not check and release the bitmaps returned from STM_SETIMAGE messages, the bitmaps are leaked.

So by adding this code (to each of the STM_SETIMAGE calls) i resolved my memory leak issue:

Invoke SendDlgItemMessage, hWin, IDC_TT_Status,  STM_SETIMAGE, IMAGE_BITMAP, hPngBmp_TT_Online
.IF eax != NULL
   Invoke DeleteObject, eax
.ENDIF

Must have spent last 2 days in total wading through code and trying stuff with threads and refining code and data variables all for it to be a resource problem, but my code and data is better setup now i feel, so im happy that i caught this and can have it running for days in the traybar without any memory leaks :D

Ive attached some pics of the program, thanks for reading my mini-blog/forum post adventure. :D

[hutch--]

Sounds like a ton of fun.  :bg

[fearless]

True, i suppose these little things come along to test us, and once conquered we can look back and smile.

Hopefully someone else finds my post useful in future if they run into a similar problem.