GDI Resource leaks - CXTPDialogBaseImpl

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   When constructing a dialog derived from CXTPDialogBaseImpl the base class creates a CXTPCommandBars object. In its constructor a CXTPCustomizeDropSource object is created and in its constructor 3 icons are loaded. Our GDI resource leak tool is identifying these as resource leaks. I ran the tool because I noticed the GDI count going up in our process whenever we launch a dialog that uses this base class. Where is the DestroyIcon code supposed to go. Looks like it should be in destructor which is devoid of code.

CXTPCustomizeDropSource::CXTPCustomizeDropSource(CXTPCommandBars* pCommandBars)
{
    m_hcurDelete   = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGDELETE);
    m_hcurMove     = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGMOVE);
    m_hcurCopy     = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGCOPY);
    m_pSheet       = NULL;
    m_pCommandBars = pCommandBars;

    m_hwndCapture = 0;
    m_pControl    = 0;
    m_bMove          = FALSE;
    m_bCopyOnly   = FALSE;
    m_pTarget     = NULL;
}

CXTPCustomizeDropSource::~CXTPCustomizeDropSource()
{
}

This is in the current release.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 890	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: GDI Resource leaks - CXTPDialogBaseImpl Posted: 16 December 2024 at 8:47am
	When constructing a dialog derived from CXTPDialogBaseImpl the base class creates a CXTPCommandBars object. In its constructor a CXTPCustomizeDropSource object is created and in its constructor 3 icons are loaded. Our GDI resource leak tool is identifying these as resource leaks. I ran the tool because I noticed the GDI count going up in our process whenever we launch a dialog that uses this base class. Where is the DestroyIcon code supposed to go. Looks like it should be in destructor which is devoid of code. CXTPCustomizeDropSource::CXTPCustomizeDropSource(CXTPCommandBars* pCommandBars) { m_hcurDelete = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGDELETE); m_hcurMove = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGMOVE); m_hcurCopy = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGCOPY); m_pSheet = NULL; m_pCommandBars = pCommandBars; m_hwndCapture = 0; m_pControl = 0; m_bMove = FALSE; m_bCopyOnly = FALSE; m_pTarget = NULL; } CXTPCustomizeDropSource::~CXTPCustomizeDropSource() { } This is in the current release.

agontarenko Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 25 March 2016 Status: Offline Points: 298	Post Options Post Reply Quote agontarenko Report Post Thanks(0) Quote Reply Posted: Yesterday at 4:20am
	Hello, What GDI resource leak tool you used for identifying resource leaks? Regards, Artem Gontarenko

agontarenko Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 25 March 2016 Status: Offline Points: 298	Post Options Post Reply Quote agontarenko Report Post Thanks(0) Quote Reply Posted: Yesterday at 4:22am
	How I can to reproduce this?

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 890	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: Yesterday at 9:33am
	We have a tool we wrote that hooks various APIs and tracks resource allocations. It uses debugging APIs to capture call stacks on allocation. When it lists any outstanding allocations we can double click an entry it shows on a call stack and it opens the source file in Visual Studio. It lets us start tracking and stop tracking on demand. So, I started tracking, brought up a dialog derived from the CJ class, closed the dialog and stopped tracking. Then I listed all outstanding resources and saw the "icon" resources and followed the stack and code. I fixed this in the destructor by checking for non-null members and calling DestroyIcon. Just set a breakpoint in the constructor and destructor and you can see the allocation and see in the destructor the members are non null.

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 890	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: Yesterday at 10:43am
	uploads/3213/CJLeak.zip Video of ISpy detecting GdiCursor leak in toolkit pro.

agontarenko Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 25 March 2016 Status: Offline Points: 298	Post Options Post Reply Quote agontarenko Report Post Thanks(0) Quote Reply Posted: 9 hours 41 minutes ago at 4:13am
	Hello, I've changed code by calling GetGuiResources before and after LoadIcon/DestroyCursor/DestroyIcon and GetGuiResources returns same value before and after DestroyCursor/DestroyIcon functions. So this functions not clean GDI resources after LoadIcon call. Next I've more detail checked MSDN documentation and found one thing: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-destroycursor Remarks : The DestroyCursor function destroys a nonshared cursor. Do not use this function to destroy a shared cursor. A shared cursor is valid as long as the module from which it was loaded remains in memory. The following functions obtain a shared cursor: LoadCursor... https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-destroyicon In remarks of DestroyIcon function wrore same. Remarks: It is only necessary to call DestroyIcon for icons and cursors created with the following functions: CreateIconFromResourceEx (if called without the LR_SHARED flag), CreateIconIndirect, and CopyIcon. Do not use this function to destroy a shared icon. A shared icon is valid as long as the module from which it was loaded remains in memory. The following functions obtain a shared icon. LoadIcon... So I thik this is not a bug. Regards, Artem Gontarenko