CXTPObservable leaks causing aborts

I have found this code is asserting in XTPSystemHelpers.h:

template<class Owner, class Observer>
AFX_INLINE CXTPObservable<Owner, Observer>::~CXTPObservable()
{
    ASSERT("All observers must be unsubscribed before destruction" && 0 == m_Observers.GetSize());
}

This causes random crashes when closing a debug build when the user has the Win 10 OS setting to use the cursor text indicator. The crash happens when the ASSERT code does a PeekMessage call. The crash is deep in UIAutomationCore.dll during the PeekMessage call.

So why is CJ asserting? I traced this to using the CXTPRibbonOffice2013Theme which creates some CXTPMarkupColor objects (CXTPMarkUpAmbientColor and CXTPMarkUpAmbientColorBrush). Further, it looks like to me the reason is the global paint manager leaking.

I found CXTPPaintManager::SetCustomTheme calls SetGlobalPaintManager. I have found no call during XTPShutDown that releases the global paint theme. So, I get this ASSERT as there are still observables in existence. I do see SetCustomTheme will assert if I pass in null. So that is not something that should be called with null. The SetCustomTheme code spins the ref count down for the current global paint manager so it gets released when setting a new theme. But the new theme just ... remains

This happens in our app. So, I ran the RibbonMDISample in debug. After it comes up, I go to the styles and change the style from Office 2016 Word to Office 2013 Word. Then I exit. The same ASSERT is called for the same reason - 4 observables in one of the arrays of observables.

So, I ask CodeJock:

What is the correct code calls to make sure this global paint manager is properly released so its destructor runs and these observables call XTPGetApplication()->Unsubscribe() and I can avoid the ASSERT/PeekMessage/RandomCrash?

I could try to call the protected GetGlobalPaintManager/SetGlobalPaintManager and spin the ref count down like SetCustomTheme does and hope no CJ code references the nullptr after that. If, I can the code to compile. The I have to worry about what this means for the future of those calls:

    _XTP_DEPRECATED_IN_FAVOR2(GetGlobalPaintManager, SetGlobalPaintManager)

Hi markr,

I gave up finding what I would call a good solution to this. I can't get the global paint manager and spin its count down like SetCutomTheme does.

So, here is what I had to resort too. Right before I call XTPShutdown I did this:

    if( XTPPaintManager() )
    {
        XTPPaintManager()->SetTheme(xtpThemeOffice2000);
    }

That is the default theme CJ creates in V20. Unfortunately, sometimes there is no global paint manager, which is why we don't always trap the fact there are observable leaks. So, in that case CJ creates a new theme and it will be the xtpThemeOffice2000 theme and there is no leaking. To avoid creating two of that theme, I can use this:

    if( XTPPaintManager() )
    {
        XTPPaintTheme curTheme = XTPPaintManager()->GetCurrentTheme();
        if( xtpThemeOffice2000 != curTheme )
        {
            XTPPaintManager()->SetTheme(xtpThemeOffice2000);
        }
    }

I dislike doing this but the alternative is risking crashes in debug when shutting down while the OS Text Cursor Indicator setting is on. And, I like a crash free shutdown of our app even in debug.

> Have you turned on the OS Text Cursor Indicator?

No, but I have noticed that if I launch the Windows magnifier (I used it sometimes to align small UI facets) then I'll see debug crashes similar to what you describe.

> but CJ just goes right ahead and accesses with no checks

This type of mistake is quite common in the XTP source code, I'm afraid.

I did look at the objects and found they were "ambient" color and brush objects. I set a BP in the code and found they are created when we start up and set our theme to office 2013. That let me see that theme object was "stuck" as the global paint manager. I didn't find any leaks. But, SetCustomTheme will spin down the count until the current one is released. So, I finally just set the theme back to the 2003 (default theme) CJ sets at startup. The code released the 2013 theme and the leaks went away with it. Tracking leaks is tough as there was a ref count of well over 900 on the paint manager. Guess that's why SetCustomTheme does this at the end to the global PM it grabs at the top of the code before setting it to the new theme:

        while (0 < pOldTheme->InternalRelease())
            ;

The conclusion is that the issue is caused by an injected UI automation module and hence it cannot be fixed properly on ToolkitPro side. If you find that the suggested workaround works well in your project then please keep using it. 

Regards,

   Alexander

Hi Astoyan,

How can I verify UIAutomation ref leaks? Have you posted on the MSDN forums regarding them? I have posted on the forums stating that the text cursor indicator setting is crashing our app. But, about all I got back was "how to repro" it. If you can mock up a sample, or modify one of your samples, that show the leaks, that would be good to use as a post. And, I would gladly post it.

Or ... we pay big, big bucks for MS support. If I have a sample, or can even point to the code where you know a ref leak is created, I can send MS our application and instructions on what code is calling into the application so MS can examine the issue and hopefully provide a fix.

I would love to be able to point to the docking pane code as UIAutomation appears to be causing our customers the most pain (i.e., user crashes).

We have crashes where the customer isn't using the Text Cursor Indicator but we get crashes in the docking pane code and the dump files show UIAutomation is injected. Yet, on my box, I can only find it injected into the app if I use the cursor indicator setting.

I have an active subscription and ticket on the support. I haven't get a reply yet.