Several show-stopping problems

[klight]

I can also confirm it's fixed.
Thank you!

[ikolev]

Big thanks from me too. It's working now.

Another good news is that C::B has not crashed on me yet since I installed the nightly build in a clean folder. I guess this is worth mentioning somewhere (e.g. in some instructions for installing the nightly builds). Unless it is mentioned and I have missed it.

[takeshimiya]

Big thanks from me too. It's working now.

Another good news is that C::B has not crashed on me yet since I installed the nightly build in a clean folder. I guess this is worth mentioning somewhere (e.g. in some instructions for installing the nightly builds). Unless it is mentioned and I have missed it.

What would be good to understand is why the crashes.
The configuration can't be, as it was saved in the registry.
The old lexers/resources/etc shouldn't crash C::B, because they hadn't changed much, and all the code is backwards compatible.

The only thing that could produce the crash would be old shared libraries.

Like old plugins with different name or not in new versions (as the svn plugin).
But if that's the case, loading plugins made for a previous SDK shouldn't load, as they are versioned.

The other cause could be that the wxWidgets dll shipped with RC2 was another version (2.6.1?).
But if that's the case, we should start building wxWidgets as wxmsw262u instead of wxmsw26u.
Or another option could be to check upon C::B load at runtime, if the main app and plugins were compiled against the same configuration&version of wxWidgets dll.

So, what could be the problem?

[thomas]

The old lexers/resources/etc shouldn't crash C::B, because they hadn't changed much, and all the code is backwards compatible.

As it happens, those are the likely reason.

The only thing that could produce the crash would be old shared libraries.
Like old plugins with different name or not in new versions (as the svn plugin).

No, Takeshi.

[takeshimiya]

The old lexers/resources/etc shouldn't crash C::B, because they hadn't changed much, and all the code is backwards compatible.

As it happens, those are the likely reason.

It is spotted which are exactly?
I don't understand which one could be, as most resources are loaded from the zips, and all those are overwritten by new versions because they have the same name. And the lexers have the same name too.

Doing a diff of all files between RC2 and HEAD, gives the next sensible files missing in HEAD:

CodeBlocks/share/CodeBlocks/plugins/cbDragScroll.dll
CodeBlocks/share/CodeBlocks/plugins/FileTabMenu.dll
CodeBlocks/share/CodeBlocks/plugins/svn.dll
CodeBlocks/share/CodeBlocks/svn.zip
CodeBlocks/mingwm10.dll
CodeBlocks/wxmsw26_gcc_cb.dll

So those are the ones that could introduce a problem, the rest are overwritten by same-name files.

That is, unless ikolev had click "don't overwrite files" when uncompressing Nighlty over RC2.

[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]

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).

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.

It is, however, quite counter-productive to discuss this.

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]

That is, unless ikolev had click "don't overwrite files" when uncompressing Nighlty over RC2.

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]

http://www.ikolev.com/files/codeblocks.rpt.zip

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;
}

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]

[ikolev]

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!

Note that this happens only with a "crippled" installation, i.e. unzipping a nightly build on top of an RC2 install. I don't get these crashes with cleanly installed nightly builds. (BTW, now I'm unzipping each new nightly build on top of the previous ones, so such problems *might* appear again - we'll see.)
I think CB developers should not waste time chasing such problems, at least for now... I don't have much time myself. I thought that the .rpt file might be enough to find the problem, but if it isn't, better not waste further efforts on this. If you insist though, I have saved the crippled installation and can do some debugging, or hand it over to someone who has more time

[mandrav]

The reason for the crashes in your rpt file have been recently fixed (just a couple of days ago).