User forums > Help
Several show-stopping problems
thomas:
There are (at least) two things which may cause a crash. The plugins are certainly not among them. Plugins are checked for their SDK version before anything is initialised.
The first thing that will crash is either dereferencing a pointer obtained by XRCCTRL just before the first dialog shows or while the main menu bar is being created, whichever happens first.
The second thing that will crash is wxDialog::ShowModal because of a version conflict in the two wxWidgets libraries (but you never get that far, anyway).
It is, however, quite counter-productive to discuss this. It only encourages people to actually try and do it, which they should not. We have enough things to deal with already, no need to invent new complications by mixing versions.
takeshimiya:
--- Quote from: thomas on March 13, 2006, 11:47:19 pm ---The second thing that will crash is wxDialog::ShowModal because of a version conflict in the two wxWidgets libraries (but you never get that far, anyway).
--- End quote ---
Actually, I think that's the most probable reason.
I've experienced (not on purpose) a strange crash where I couldn't understand what was happening, or why was C::B crashing.
It costed me 2 days, until I opened a plugin with a dependecy scanner, and noticed that it was trying to use a non-unicode wxWidgets symbols, whereas I had a unicode wxWidgets dll.
But the point is that it let me go that far away, and those kind of problems aren't rare.
--- Quote from: thomas on March 13, 2006, 11:47:19 pm ---It is, however, quite counter-productive to discuss this.
--- End quote ---
No, it isn't. Not discussing problems is not good, more when it can be solved.
I want to know what are the reasons, and then fix it if possible, by any means.
As ikolev demostrated, it is a serious problem, and he is not the first to have it.
The ways that could solve it are:
*Putting on first run, a messagebox warning "don't mix versions". (not good)
*Checking if the wxWidgets dll configuration is the same as the plugins/program, at runtime.
Again, mixing versions isn't bad generally, in other programs. Indeed, an example is Firefox.
A recommended way to upgrade is to put new versions over the older versions.
What they clarify, it's to never mix the profile folder of different versions (in C::B the equivalent would be mix the configuration files).
Also, keep in mind that in the future C::B could update itself, just like Dev-C++ did.
I even recall Yiannis saying it at some time.
So if we don't solve the problem now, we will keep getting more reports of this kind. :(
ikolev:
--- Quote from: Takeshi Miya on March 13, 2006, 11:19:50 pm ---That is, unless ikolev had click "don't overwrite files" when uncompressing Nighlty over RC2.
--- End quote ---
I surely haven't done that (what's the point to _update_ an existing installation without overwriting files with the new ones?)
I tend to agree that these problems are better sorted out if C::B plans to be regularly updated, and especially if it plans to support mixed version plugins (i.e. plugins written for previous or later versions of C::B).
I want to remind about the other problem (not just the crashes) which can give some clues - the messed up project dependencies after loading a workspace. Generally, what happened was that one of the projects was automatically set as a dependency for all others.
And I can also give you the .rpt file which I kept, hoping that it can be of help - http://www.ikolev.com/files/codeblocks.rpt.zip
Regards,
Ivan
MortenMacFly:
--- Quote from: Ivan Kolev on March 14, 2006, 10:53:38 am ---http://www.ikolev.com/files/codeblocks.rpt.zip
--- End quote ---
Well, the file shows that the source for many crashes is cbProject::SaveAllFiles. The code of this method looks like that:
--- Code: ---bool cbProject::SaveAllFiles()
{
int count = m_Files.GetCount();
FilesList::Node* node = m_Files.GetFirst();
while(node)
{
ProjectFile* f = node->GetData();
if (Manager::Get()->GetEditorManager()->Save(f->file.GetFullPath()))
--count;
node = node->GetNext();
}
return count == 0;
}
--- End code ---
What could not work here? the ProjectFile could be NULL, Manager::Get()->GetEditorManager() could return NULL. You could easily add such verification yourself and help us to discover what's happening. I use C::B daily with large projects and workspaces (around 1500 files and workspaces with around 40 projects). This never happens to me so it is really difficult to verify. It's OpenSource so you really could help - please!
With regards, Morten.
takeshimiya:
From the call stack here are the functions causing trouble (the most frequent is the wxListBase::GetCount() one):
1) sdk/workspaceloader.cpp
WorkspaceLoader::Save(wxString const&, wxString const&)
cbWorkspace::Save(bool)
ProjectManager::SaveWorkspace()
2) sdk/messagemanager.cpp
MessageManager::DebugLogError(wchar_t const*, ...)
ProjectManager::DoOpenFile(ProjectFile*, wxString const&)
ProjectManager::DoOpenSelectedFile()
ProjectManager::OnProjectFileActivated(wxTreeEvent&)
3) sdk/cbworkspace.cpp
cbWorkspace::Save(bool)
ProjectManager::SaveWorkspace()
ProjectManager::QueryCloseWorkspace()
ProjectManager::CloseWorkspace()
4) sdk/cbproject.cpp
wxListBase::GetCount() const [sdk]
cbProject::SaveAllFiles() [sdk]
PluginSDKVersion [compilergcc]
5) sdk/cbproject.cpp
wxNodeBase::GetData() const [sdk]
wxFilesListNode::GetData() const [sdk]
cbProject::SaveAllFiles() [sdk]
PluginSDKVersion [compilergcc]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version