Now I can reproduce, this is the stack trace:
#0 0x62da1cb8 in wxChoice::GetString(unsigned int) const () from C:\Windows\system32\wxmsw315u_gcc_custom.dll
#1 0x6c32422f in FileExplorerUpdater::Update (this=0x20572958, ti=...)
at G:\cbtrunk\src\plugins\contrib\FileManager\FileExplorerUpdater.cpp:153
#2 0x6c30a1ba in FileExplorer::OnTimerCheckUpdates (this=0x205c07e0)
at G:\cbtrunk\src\plugins\contrib\FileManager\FileExplorer.cpp:594
#3 0x62a43222 in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const ()
from C:\Windows\system32\wxmsw315u_gcc_custom.dll
#4 0x0028d57c in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The code in that function is very strange, why use
m_path=wxString(m_fe->GetFullPath(ti).c_str());
m_path=m_fe->GetFullPath(ti);
EDIT: around line 1260 there is an almost identical code snippet, you can still get an assert from it later.
FileExplorerUpdater::Update() and VCSFileLoader::Update() are called (or should be called) from the main thread and they start the threads:
void Update(const wxTreeItemId &ti); //call on main thread to do the background magic
void Update(const wxString &op, const wxString &source_path, const wxString &destination_path, const wxString &comp_commit); //call on main thread to do the background magic
And in the official documentation :
wxString wxEmptyString
The global wxString instance of an empty string.
Used extensively in the entire wxWidgets API.
I have also seen that a few guys had problem with this wxEmptyString, but the doc seem to say it's good and used extensively. It's also said it's a wxString but effectively seen as a wxChar* inside C::B (which use it more than 600 times in it's workspace :-[). so ?? not so bad !