This happens when a search is started because of an inconsistent use of "long" and "unsigned int".
Here's a patch:
--- codeblocks-1.0svn.orig/src/plugins/contrib/ThreadSearch/ThreadSearchView.cpp 2008-01-23 12:50:35.000000000 +0100
+++ codeblocks-1.0svn.work/src/plugins/contrib/ThreadSearch/ThreadSearchView.cpp 2008-01-28 20:06:18.000000000 +0100
@@ -668,7 +668,7 @@
idCboSearchExpr
};
- for ( unsigned int i = 0; i < sizeof(idsArray)/sizeof(unsigned int); ++i )
+ for ( unsigned int i = 0; i < sizeof(idsArray)/sizeof(idsArray[0]); ++i )
{
wxWindow* pWnd = wxWindow::FindWindow(idsArray[i]);
if ( pWnd != NULL )
@@ -682,7 +683,7 @@
}
}
- for ( unsigned int i = 0; i < sizeof(toolBarIdsArray)/sizeof(unsigned int); ++i )
+ for ( unsigned int i = 0; i < sizeof(toolBarIdsArray)/sizeof(toolBarIdsArray[0]); ++i )
{
m_pToolBar->FindControl(toolBarIdsArray[i])->Enable(enable);
}
"idsArray" and "toolBarIdsArray" are Arrays of long.
"long" is 64-Bit on x86_64 systems and "unsigned int" is only 32-Bit, so the for-loops try to read the ids from behind the arrays bounds and so cause some error windows and then in the most cases a crash.
You can of course use "sizeof(long)" instead of "sizeof(idsArray[0])", but I think the second is more secure, because it's independent from the type you chose.