Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Segmentation fault in nativeparser.cpp

<< < (3/4) > >>

ollydbg:
I get similar crash, but not the same bt as yours.

Q:

--- Code: ---cbProject* ProjectManager::LoadProject(const wxString& filename, bool activateIt)
{
    cbProject* result = 0;
    if (!wxFileExists(filename) || !BeginLoadingProject())
    {
        return 0;
    }

    // "Try" block (loop which only gets executed once)
    // These blocks are extremely useful in constructs that need
    // premature exits. Instead of having multiple return points,
    // multiple return values and/or gotos,
    // you just break out of the loop (which only gets executed once) to exit.
    do
    {
        cbProject* project = IsOpen(filename);
        if (project)
        {
            // already open
            result = project;
            break;
        }

        if (FileTypeOf(filename) == ftCodeBlocksProject)
        {
            project = new cbProject(filename);

            // We need to do this because creating cbProject allows the app to be
            // closed in the middle of the operation. So the class destructor gets
            // called in the middle of a method call.

            if (!project->IsLoaded())
            {
                delete project;
                break;
            }

            result = project;
        }
        else // !ftCodeBlocksProject
        {
            // the plugin handler should call begin/end on its own...
            EndLoadingProject(0);

            cbMimePlugin* plugin = Manager::Get()->GetPluginManager()->GetMIMEHandlerForFile(filename);
            if (plugin)
                plugin->OpenFile(filename);
        }

        break;
    }  while (false);
    // we 're done

    EndLoadingProject(result);
    if (activateIt)
    {
        if (m_IsLoadingWorkspace)
            // postpone the call to SetProject() until EndLoadingWorkspace() is called
            // (we must call RebuildTree() before SetProject() is called)
            m_pProjectToActivate = result;
        else
            SetProject(result, true);
    }

    return result;
}

--- End code ---

I don't understand this comment.

--- Code: ---            // We need to do this because creating cbProject allows the app to be
            // closed in the middle of the operation. So the class destructor gets
            // called in the middle of a method call.

            if (!project->IsLoaded())
            {
                delete project;
                break;
            }

--- End code ---
The project may be deleted when loading? I don't know how it did.

ollydbg:
Today, I try to reproduce this crash.

Firstly, I disable all the plugins except Codecompletion plugin, and I can't reproduce the crash
But after I enable the Compiler plugin, then I can reproduce the crash.

So, can anyone confirm this? Thanks.

In CC's code, it will call some compiler's function to get some include paths of GCC, maybe it is un-safe.

EDIT: Should the Compiler plugin be detached/destroyed after CC plugin?

Jenna:

--- Quote from: ollydbg on March 16, 2013, 10:06:52 am ---Today, I try to reproduce this crash.

Firstly, I disable all the plugins except Codecompletion plugin, and I can't reproduce the crash
But after I enable the Compiler plugin, then I can reproduce the crash.

So, can anyone confirm this? Thanks.

In CC's code, it will call some compiler's function to get some include paths of GCC, maybe it is un-safe.

EDIT: Should the Compiler plugin should be detached after CC plugin?

--- End quote ---

There are other crash, that only occur when cc- and compiler-plugin are enabled (if I remember correctly).

If one plugin depends on another it's always unsafe, and we should have some kind of dependency and priority checking for the plugins, to force a load and unload-order.

But in my opinion no plugin should try to use other plugins funnctions before all plugins are loaded (that might not work, if some functions are used for initializing) and after unloading plugins has started.

This will not cover the problem of one plugin depending on another one in normal use.
So the dependency and priority approach might be better.

ollydbg:

--- Quote ---There are other crash, that only occur when cc- and compiler-plugin are enabled (if I remember correctly).

If one plugin depends on another it's always unsafe, and we should have some kind of dependency and priority checking for the plugins, to force a load and unload-order.

But in my opinion no plugin should try to use other plugins funnctions before all plugins are loaded (that might not work, if some functions are used for initializing) and after unloading plugins has started.

--- End quote ---
The crash happens like below steps(I guess):
1, app started
2, both cc and compiler plugin loaded correctly
3, user open a cbp project
4, cc start parsing (after some timer delay) and query compiler search path from compiler plugin(this internally call gcc command line)
5, user click the "close" button of the app

Then, I guess compiler destroyed before cc, so crash happens.


--- Quote ---This will not cover the problem of one plugin depending on another one in normal use.
So the dependency and priority approach might be better.
--- End quote ---
Yes, I think priority approach is good.

oBFusCATed:

--- Quote from: ollydbg on March 16, 2013, 10:28:13 am ---Then, I guess compiler destroyed before cc, so crash happens.

--- End quote ---
Probably you can add an event which notifies all plugins that the unload process has started, so they can clean themselves and they can untangle some of the dependencies.

Navigation

[0] Message Index

[#] Next page

[*] Previous page