Since Code::Blocks switched to wx2.8.3 on windows I've successfully reproduced this issue with the latest nightly (rev3888). Here is the report:
Error occured on Thursday, April 26, 2007 at 14:47:23.
C:\Programme\Entwicklung\cb-test\codeblocks.exe caused an Access Violation at location 6cde357c in module C:\Programme\Entwicklung\cb-test\wxmsw28u_gcc_cb.dll Reading from location 00000028.
Registers:
eax=00000000 ebx=00000003 ecx=00000000 edx=ffff0000 esi=ffffffff edi=030afb30
eip=6cde357c esp=030afaf8 ebp=030afb50 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
Call stack:
6CDE357C C:\Programme\Entwicklung\cb-test\wxmsw28u_gcc_cb.dll:6CDE357C _ZNK10wxTreeCtrl12GetItemParamERK12wxTreeItemId
6CDE3768 C:\Programme\Entwicklung\cb-test\wxmsw28u_gcc_cb.dll:6CDE3768 _ZNK10wxTreeCtrl11GetItemDataERK12wxTreeItemId
6CE8A38D C:\Programme\Entwicklung\cb-test\wxmsw28u_gcc_cb.dll:6CE8A38D _ZN11wxTreeEventC1EiP14wxTreeCtrlBaseRK12wxTreeItemId
6CDE5566 C:\Programme\Entwicklung\cb-test\wxmsw28u_gcc_cb.dll:6CDE5566 _ZN10wxTreeCtrl8DoExpandERK12wxTreeItemIdi
6CDE5891 C:\Programme\Entwicklung\cb-test\wxmsw28u_gcc_cb.dll:6CDE5891 _ZN10wxTreeCtrl16CollapseAndResetERK12wxTreeItemId
65EA09D1 C:\Programme\Entwicklung\cb-test\share\codeblocks\plugins\codecompletion.dll:65EA09D1
65E9E6B9 C:\Programme\Entwicklung\cb-test\share\codeblocks\plugins\codecompletion.dll:65E9E6B9
65E9E3F7 C:\Programme\Entwicklung\cb-test\share\codeblocks\plugins\codecompletion.dll:65E9E3F7
65E9DF2F C:\Programme\Entwicklung\cb-test\share\codeblocks\plugins\codecompletion.dll:65E9DF2F
6CCFEBAB C:\Programme\Entwicklung\cb-test\wxmsw28u_gcc_cb.dll:6CCFEBAB _ZN11wxSemaphore7TryWaitEv
6CCFECBD C:\Programme\Entwicklung\cb-test\wxmsw28u_gcc_cb.dll:6CCFECBD _ZN11wxSemaphore7TryWaitEv
77C0A3B0 C:\WINDOWS\system32\msvcrt.dll:77C0A3B0 _endthreadex
7C80B683 C:\WINDOWS\system32\kernel32.dll:7C80B683 GetModuleFileNameA
I've also tested my own build some more and from time to time (when closing a workspace with many projects) it was unstable with the above posted solution too, so I've modified
ClassBrowserBuilderThread::BuildTree to freeze the trees earlier. Now it looks like this:
void ClassBrowserBuilderThread::BuildTree()
{
if (Manager::IsAppShuttingDown())
return;
// wxMutexLocker lock(m_BuildMutex);
//Freezing moved to the beginning
m_pTreeTop->Freeze();
m_pTreeBottom->Freeze();
//Clear the browser, if there is no active project
if(!Manager::Get()->GetProjectManager()->GetActiveProject())
{
m_pTreeTop->DeleteAllItems();
m_pTreeBottom->DeleteAllItems();
}
m_pTreeTop->SetImageList(m_pParser->GetImageList());
m_pTreeBottom->SetImageList(m_pParser->GetImageList());
wxTreeItemId root = m_pTreeTop->GetRootItem();
if (!root.IsOk())
{
root = m_pTreeTop->AddRoot(_("Symbols"), PARSER_IMG_SYMBOLS_FOLDER, PARSER_IMG_SYMBOLS_FOLDER, new CBTreeData(sfRoot));
m_pTreeTop->SetItemHasChildren(root);
}
RemoveInvalidNodes(m_pTreeTop, root);
RemoveInvalidNodes(m_pTreeBottom, m_pTreeBottom->GetRootItem());
if (TestDestroy() || Manager::IsAppShuttingDown())
{
m_pTreeBottom->Thaw();
m_pTreeTop->Thaw();
return;
}
// the tree is completely dynamic: it is populated when a node expands/collapses.
// so, by expanding the root node, we already instruct it to fill the top level :)
//
// this technique makes it really fast to draw (we only draw what's expanded) and
// has very minimum memory overhead since it contains as few items as possible.
// plus, it doesn't flicker because we 're not emptying it and re-creating it each time ;)
m_pTreeTop->Expand(root);
if(platform::gtk)
{
// seems like the "expand" event comes too late in wxGTK,
// so make it happen now
ExpandItem(root);
}
m_pTreeBottom->Thaw();
m_pTreeTop->Thaw();
SelectNode(m_pTreeTop->GetSelection()); // refresh selection
}
This seems to be quite stable. Even closing a big workspace, while "global functions" is selected in the symbols browser, doesn't make Code::Blocks crash anymore.