Crash where I could need some help (RPT)

[MortenMacFly]

Dear devs,
rarely C::B crashes for me when I open a (huge) workspace -> usually the C::B workspace with all contrib and other plugins. I've attached a crash report where I demangeled the addresses to lines of code according to my version of C::B (Version 1.0 revision 2580 () gcc 3.4.5 Windows/unicode). I don't get what should go wrong here, espeacially I don't understand why cbproject.cpp:1054 should fail, but this is a bug that I've experienced quite some time now.
Any ideas?
With regards, Morten.

[attachment deleted by admin]

[thomas]

Have not observed any such thing, and I couldn't guess why GetCount() would crash, either (don't get me started on wxWidgets, lol).

However, we don't really need to know the count anyway. All we do is count down to zero and check whether it is really zero. This can be implemented more efficiently:

Code Select Expand

bool cbProject::SaveAllFiles()
{
    bool feelGood = true;
    FilesList::Node* node = m_Files.GetFirst();
    while(node)
    {
        ProjectFile* f = node->GetData();
        if (!Manager::Get()->GetEditorManager()->Save(f->file.GetFullPath()))
            feelGood = false;
        node = node->GetNext();
    }
    return feelGood;
}

That will 99.9% certain not fix your problem (as the call to GetCount() actually cannot be the cause), but try it nevertheless

[MortenMacFly]

This can be implemented more efficiently: [...]

That will 99.9% certain not fix your problem (as the call to GetCount() actually cannot be the cause), but try it nevertheless

Thanks!!! I've applied the patch and now I'm going to wait for the next crash... this can take a while becasue as I said: There is no way to reproduce and it occures only rarely.
I hope that when it crashes again the trace will point to another line in the code that actually causes the issue - so it's really worth a try.
BTW: I saw you've committed cbexecute.h. You once provided me with a patch that replaced all wxExecute with (this) cbExecute. Allthough I've still applied this patch it did not change anything. Please remember that this patch was actually for the same issue as within this thread. But anyway... it in fact doesn't harm. ;-)
With regards, Morten.

[thomas]

I saw you've committed cbexecute.h.

I was reverting all local modifications in my working copy this morning to get a fresh, pristine copy, and stumbled over that one again.
It seemed a pity to simply throw it away, so I committed it even though the code does not currently use it.
That way, we may change the tool manager and the CC plugin any time later to use it, if we want - or we may as well delete it at a later time

[Pecan]

Code Select Expand

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


My guess: m_Files is not checked to see if it's 0x0. That's usually the cause of crashes in wxWidgets calls like this.

[/code]

[thomas]

My guess: m_Files is not checked to see if it's 0x0. That's usually the cause of crashes in wxWidgets calls like this.

Right. Except it is an auto object, not a pointer.

[Der Meister]

Thus we should perhaps check if this is valid. Because m_Files can only be invalid if the whole instance is invalid. Did anyone check this (must be an error a few levels above in the call-stack)?

[MortenMacFly]

Thomas!
It happend again (horray :?). With your patch applied the same crash happened when I opened a quite large workspace with 3 projects (large in number of files). Thi I immediately tried to compile and crash boom bang!
Please notice that I've disabled the codecomletion plugin so this isn't the source.
This time the crash happens in the line:

Code Select Expand

FilesList::Node* node = m_Files.GetFirst();
again in the method bool cbProject::SaveAllFiles().Alltogether this really looks like m_Files could be a null pointer under certain customstances... What to do? Because checking all access to m_Files for a NULL pointer seems a bad solution. Why can m_Files be NULL at this point?! I don't get it...?!
With regards, Morten.