It's hard to judge from afar, but i don't think they've made enough effort to hunt down these crashes. Saying "it's wxWidgets fault", just because the last line of the call stack is inside wxWidgets is pretty bold.
Just for fun, i downloaded their source and looked into one of the methods that crashed:
Code: Select all
void frmMain::OnSelRightClick(wxTreeEvent &event)
{
wxTreeItemId item = event.GetItem();
if (item != browser->GetSelection())
{
browser->SelectItem(item);
// Prevent changes to "currentObject" by "execSelchange" function by another thread.
// Will hold the lock until we do popup on the respective object.
//
s_currentObjectMutex.Lock();
currentObject = browser->GetObject(item);
}
if (currentObject)
doPopup(browser, event.GetPoint(), currentObject);
s_currentObjectMutex.Unlock();
}
The fact that the s_currentObjectMutex.Lock() call is inside the if() clause, but the s_currentObjectMutex.Unlock() is outside, is not good. Because if the if() clause it false, they will call Unlock() on an already unlocked mutex. Which is the cause of the crash.
Just the fact that they (think they) have to use mutexes in this code, is already suspicious in itself, but without knowing the "bigger picture", i can't say anything more about it.
There is no doubt that there are many bugs in wxWidgets, but nevertheless i'm using it since wx 2.6.1 (>10 years) on a professional level. And if you find a bug and are able to present a way to reproduce it, it will be usually fixed pretty fast. Probably faster than in any comparable toolkit. But as the wxWidgets team is pretty small, it depends on the cooperation of its users. Just saying "It crashes all the time" won't get anything fixed.
