|
We have a number of crashes in the customer base for a few years now. Almost always have the same call CJ stack or one closely related to it related to drawing a pane or getting a tooltip from a pane. Here is the most common one:
ToolkitPro1930vc160x64U.dll!CXTPDockingPane::GetOptions() Line 502 C++
ToolkitPro1930vc160x64U.dll!CXTPDockingPaneTabbedContainer::IsTitleVisible() Line 577 C++
ToolkitPro1930vc160x64U.dll!CXTPDockingPanePaintManager::AdjustCaptionRect(const CXTPDockingPaneTabbedContainer *, CRect &) Line 772 C++
ToolkitPro1930vc160x64U.dll!CXTPDockingPaneOffice2013Theme::DrawPane(CDC *, CXTPDockingPaneTabbedContainer *, CRect) Line 230 C++
ToolkitPro1930vc160x64U.dll!CXTPDockingPaneTabbedContainer::OnPaint() Line 561 C++
Today I got lucky and attached a debugger while I had release PDB files available and the call stack is the one above. Here is what I found. Notice CJ handles a nullptr m_pLayout:
CXTPDockingPaneManager* CXTPDockingPaneBase::GetDockingPaneManager() const
{
ASSERT(m_pLayout);
if (!m_pLayout)
return NULL;
ASSERT(m_pLayout->m_pManager);
return m_pLayout->m_pManager;
}
However, check out the code that crashed us:
DWORD CXTPDockingPane::GetOptions() const
{
return GetDockingPaneManager()->m_dwDefaultPaneOptions | m_dwOptions;
}
XTPDockingPane.cpp has a lot of calls to GetDockingPaneManager()->SomeMethod(...). So, if the layout is nullptr, CJ handles that and returns nullptr but the code doesn't check the pointer.
Time to edit CJ code again and I hope CJ will address this sort of calls where code calls to get a pointer and does the "GetPointer()->" code pattern when other CJ code apparently knows the pointer being obtained can be null.
|