Very very weird crash in Docking Pane!!

Hello

I invested 3 entire days to solve a crash problem that suddenly appeared !

I started working on the sample GUI_VisualStudio and modified it to my needs.
In the last weeks I made several changes to that project until a few days ago I noticed very weired crashes.
These crashes were extremely difficult to reproduce and although I found a solution now it stays an enigma why they happened!



I noticed already at the beginning that the Xtreme Tookit is very fragile.
You make a little change and suddenly something stops working.
As I'm very wise I made a backup of my work every day because I knew that I will need it some day!
And I was right!
If I would not have had these backups I would NEVER EVER have figured out what caused these crashes.
I discovered them several days after the change that initially caused them because they are so difficult to reproduce.

So what I did was compiling all the older versions of my project and I found that version 17 does not crash while version 18 crashes.
(When I discovered it, I was working on version 26)
What did I change between my backup 17 and 18 ?
Nothing interesting. Only some minor things.
But one of these changes caused the crash:  -  something that I would NEVER have suspected.

The crashes were very weird because they appeared at different locations in the code.
But always in a destructor. (sometimes even in the destructor of CString !)
And always memory was corrupted.


But the callstack was not helpfull because the error has happened long before the crash killed the application.
So the callstack only confused me and led me to wrong assumptions.
The callstack had nothing to do with the location were the memory has got corrupted before.




To reproduce the crash I had to move around the docking panes between 20 and 30 times and each time close and restart the application.
-- Sometimes it crashed when closing the application.
-- Sometimes it crashed when docking a pane to a new place.
-- Sometimes it crashed when opening the application.

The latter case was the worst.
When the crash happened while the program starts the only chance the user has, is to delete the settings XML file.
But who of my users will know that ??
They will call the support: The application crashes!
When I looked into the XML file I could not find anything corrupt.
The file looks sane.

So what was the difference between my version 17 and 18 ?
One of the minor changes was, that I specified the ID of the icon for the pane !!
That was all !
That was my fatal "error" !

But the command SeIconId() does nothing really interesting:



I called this command in CMainFrame::OnCreate(),
but the crash happened in CMainFrame::RecalcLayout()
or sometimes in other places.

The reason for the different crash locations is that memory got corrupted and the code runs a while longer before the CPU comes to work with corrupt memory.

I have seen Codejock samples that set the icon ID in OnDockingPaneNotify() after attaching the pane.

pPane->Attach(&m_wndResourceView);
pPane->SetIconID(ICON_ID);

The disadvantage is that when starting the app for the first time the icon stays invisible until the pane gets activated by the user.
I wanted to avoid that and moved the code to CMainFrame::OnCreate().....
.....and this had catastrophical consequences!

This shows how fragile the Toolkit is:
If you assign an icon ID at the wrong location the entire application crashes and will never start again.
But this only after moving docking panes around for at least 20 times !!!

For the programmers at Codejock I give a detailed explanation how to reproduce the bug so they will hopefully fix it:

In the sample GUIVisualStudio insert into CMainFrame::OnCreate() the following code at the following location:

_________________________________________________

    if (px.LoadFromFile(m_strIniFileName))
    {
        CXTPPropExchangeSection pxTaskPanel(px.GetSection(_T("TaskPanel")));
        m_wndTaskPanel.GetGroups()->DoPropExchange(&pxTaskPanel);

        CXTPPropExchangeSection pxNormalLayout(px.GetSection(_T("NormalLayout")));
        ExchangeLayout(&pxNormalLayout);

        m_pFullScreenLayout = DYNAMIC_DOWNCAST(CXTPPropExchangeXMLNode, px.GetSection(_T("FullScreenLayout")));
        ASSERT(m_pFullScreenLayout);
    }
    else
    {
        ResetToolboxItems();       
    }

    UINT u32_Icons[] = { 520, 521, 523 };
    XTPImageManager()->SetIcons(IDB_TOOLBOXICONS, u32_Icons, 3, CSize(16,16));
    paneClassView->SetIconID(523);

    CXTPImageManager* pImageManager = pCommandBars->GetImageManager();

    pImageManager->InternalAddRef();
    m_paneManager.SetImageManager(pImageManager);

__________________________________

The following code will also invoke the crash:

    paneClassView->SetIconID(ID_FILE_SAVE);

although it is more difficult to reproduce with this code.
__________________________________

To make it easier for you so you must not move around the panes 30 times, copy this XML file into your Bin directory:

uploads/20100717_195048_GUI_VisualStudi.zip

When you add this one line of code and copy the XML file it will crash.
When you remove the line of code the SAME XML file works fine !


I Hope you will fix this bug that wasted 3 entire days of my life !!

Elmü

Hello Oleg

Yes, that is what I found out after 3 days of searching:
that the order of commands matters.

But how can an ordinary programmer know that ?
There is absolutely no manual available that explains how to do such simple things like assigning icons to a pane.
The sample code that I saw that sets the icon in OnDockingPaneNotify() are a bad example beause the icon will only show after the pane has been activated for the first time.
So the logical consequence was that I modified the sample code to get a better behaviour.

And this change crashed the application.
So if it is not a bug it is a lack of documentation that makes programmers waste their time in searching the cause of strange crashes!

How can I know that a call to ExchangeLayout() makes the pointers invalid ?
And not even always !
Only sometimes!

Elmü