GDI Object leak detection
-
First, I appologize if the answer is here somewhere but I couldn't find it. I am trying to find out where in my program I have a GDI object leak. As I run my program, the task manager reports that my GDI object count is rising. I have been programming VC++ since 4.0 and I am very verse in deleting my objects when I am done with them. However, I have run into a case where I believe it is in a Win32 call that may make a copy. I just don't know which one. For example, I just learned that CStatic::SetIcon makes a copy. I have an array of HICONs that are loaded in App::InitInstance and destroyed in App:ExitInstance. Everytime I call a CStatic::SetIcon with one of these icon handles, the GDI object count increases. The fix was to do a GetIcon first, and DeleteObject on the icon handle it returns. Program is happy now in that regard. But I still am missing some and I was wondering where. The program is graphic intensive and would be tough to start selectively commenting out the graphic calls. Any thoughts?
-
First, I appologize if the answer is here somewhere but I couldn't find it. I am trying to find out where in my program I have a GDI object leak. As I run my program, the task manager reports that my GDI object count is rising. I have been programming VC++ since 4.0 and I am very verse in deleting my objects when I am done with them. However, I have run into a case where I believe it is in a Win32 call that may make a copy. I just don't know which one. For example, I just learned that CStatic::SetIcon makes a copy. I have an array of HICONs that are loaded in App::InitInstance and destroyed in App:ExitInstance. Everytime I call a CStatic::SetIcon with one of these icon handles, the GDI object count increases. The fix was to do a GetIcon first, and DeleteObject on the icon handle it returns. Program is happy now in that regard. But I still am missing some and I was wondering where. The program is graphic intensive and would be tough to start selectively commenting out the graphic calls. Any thoughts?
Are you running the debug kernel of windows? In the old days (I mean 1994/1995) if you did so, when your process exited, if you had not freed all the GDI objects, you would get a dump when running your process under debug mode of all the GDI object you failed to 'free'. You might also find this utility helpful: http://msdn.microsoft.com/msdnmag/issues/03/01/GDILeaks/default.aspx[^]
-
First, I appologize if the answer is here somewhere but I couldn't find it. I am trying to find out where in my program I have a GDI object leak. As I run my program, the task manager reports that my GDI object count is rising. I have been programming VC++ since 4.0 and I am very verse in deleting my objects when I am done with them. However, I have run into a case where I believe it is in a Win32 call that may make a copy. I just don't know which one. For example, I just learned that CStatic::SetIcon makes a copy. I have an array of HICONs that are loaded in App::InitInstance and destroyed in App:ExitInstance. Everytime I call a CStatic::SetIcon with one of these icon handles, the GDI object count increases. The fix was to do a GetIcon first, and DeleteObject on the icon handle it returns. Program is happy now in that regard. But I still am missing some and I was wondering where. The program is graphic intensive and would be tough to start selectively commenting out the graphic calls. Any thoughts?
MFC uses a lot of object caching. As a result, you can't use the values in the Task Mgr as an accurate account of what 'you' have freed as MFC may still have the object cached. It makes it rather hard to find any real leaks. ...cmk Save the whales - collect the whole set
-
First, I appologize if the answer is here somewhere but I couldn't find it. I am trying to find out where in my program I have a GDI object leak. As I run my program, the task manager reports that my GDI object count is rising. I have been programming VC++ since 4.0 and I am very verse in deleting my objects when I am done with them. However, I have run into a case where I believe it is in a Win32 call that may make a copy. I just don't know which one. For example, I just learned that CStatic::SetIcon makes a copy. I have an array of HICONs that are loaded in App::InitInstance and destroyed in App:ExitInstance. Everytime I call a CStatic::SetIcon with one of these icon handles, the GDI object count increases. The fix was to do a GetIcon first, and DeleteObject on the icon handle it returns. Program is happy now in that regard. But I still am missing some and I was wondering where. The program is graphic intensive and would be tough to start selectively commenting out the graphic calls. Any thoughts?
prcarp wrote: appologize No need! If you feel the need, it implies you know what you're doing, but have not figured out the answer yet! It would help if you posted the leak error message. If it is happening in debug mode, the odds are that the leak reported is invalid. Since the task manager reports that the count is rising, then it probably is real. Before assuming the task manager is telling you the entire truth: give it a few minutes or try closing the IDE, to see if the task manager stops reporting the same count. If the task manager does report the same count, then try running a release version of your application and see if the same thing is still happening. Assuming (ass-u-me) that the problem is in the code you wrote, then I would put a TRACE(...) statement wherever you create a GDI object as well as where you release/free the GDI object (to see if they match). There is also the possibility that you selected a pen, brush, ect... and did not restore the original (unlikely). Oh Well! I dought if any of this helped (you already knew it). INTP "The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes." Andrew W. Troelsen
-
Are you running the debug kernel of windows? In the old days (I mean 1994/1995) if you did so, when your process exited, if you had not freed all the GDI objects, you would get a dump when running your process under debug mode of all the GDI object you failed to 'free'. You might also find this utility helpful: http://msdn.microsoft.com/msdnmag/issues/03/01/GDILeaks/default.aspx[^]
I am using WindowsXP with latest patches, etc. The task manager GDI Object count increases when I open a particular dialog box, for example. This dialog box has many CStatic-based elements which I use for some icon displays (that change based on some user WM_ events). It also has CButton-based elements for some metal-looking buttons with regions and icons. I started commenting out different pieces, trying to isolate the issue. The icons change while the dialog is open and the GDI Object count increases. It stays at that level when the dialog is closed but goes up yet again when the dialog is re-opened. To complicate matters more, I use a CMemDC to draw on before BitBlt-ing onto the CDC provided in the OnDraw. I wouldn't necessarily have an issue with this but if the program runs for hours, I get low system resource errors, the program fails to paint windows, and eventually locks up. It seems to happen more frequently when I am in front of customers. :) Task manager is the only way to kill it. I will look into the article you mentioned. I also looked at different tools (Rational Purify, Numega, etc.) but they are expensive.... I may have no alternative. Thanks!
-
MFC uses a lot of object caching. As a result, you can't use the values in the Task Mgr as an accurate account of what 'you' have freed as MFC may still have the object cached. It makes it rather hard to find any real leaks. ...cmk Save the whales - collect the whole set
I was wondering about that. I did see some cases where the count would linger before going down. However, I have some cases where it jumps up by 30 to 40 and then stays put (see response to Blake above). It gets bigger and bigger as the program stays running and eventually I get system resource errors and the program hangs.