Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

Code Completion & Workspace

<< < (4/7) > >>

ollydbg:

--- Quote ---Call stack:
65F12FAE  D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65F12FAE  _ZN8cbPlugin9OnReleaseEb
65F13015  D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65F13015  _ZN8cbPlugin9OnReleaseEb
65F12FFD  D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65F12FFD  _ZN8cbPlugin9OnReleaseEb
65F09005  D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65F09005  _ZN12cbToolPlugin9BuildMenuEP9wxMenuBar
65F0FAD0  D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65F0FAD0  _ZN8cbPlugin9OnReleaseEb
--- End quote ---
I have no idea why the crash call stack was pointing to a function named "_ZN8cbPlugin9OnReleaseEb"??? :(, it seems like that the crash caused on the plugin release?

MortenMacFly:

--- Quote from: ollydbg on May 12, 2011, 04:44:25 pm ---I have no idea why the crash call stack was pointing to a function named "_ZN8cbPlugin9OnReleaseEb"??? :(, it seems like that the crash caused on the plugin release?

--- End quote ---
I know what causes this and it happens occasionally to me, too.

I traced it back to void Parser::OnAllThreadsDone(CodeBlocksEvent& event). This line:

--- Code: ---            parseEndLog.Printf(_T("Project '%s' parsing stage done (%d total parsed files, ")
                               _T("%d tokens in %ld minute(s), %ld.%03ld seconds)."),
                               m_Project    ? m_Project->GetTitle().wx_str()  : _T("*NONE*"),
                               m_TokensTree ? m_TokensTree->m_FilesMap.size() : 0,
                               m_TokensTree ? m_TokensTree->realsize()        : 0,
                               (m_LastStopWatchTime / 60000),
                               (m_LastStopWatchTime / 1000) % 60,
                               (m_LastStopWatchTime % 1000) );

--- End code ---
...crashes C::B. Notice that actually access is protected by a wxCriticalSectionLocker and also, there are NULL pointer checks (done by me as I was hoping that would fix the crash). For the moment I don't know what actually might be the issue. Again: That's one of the bugs not reproducible. :-(

ollydbg:
@MortenMacFly
Does this crash happen on the batch parse stage?  As far as I know, void Parser::OnAllThreadsDone() was called when the batch parse finishes.

MortenMacFly:

--- Quote from: ollydbg on May 12, 2011, 05:03:35 pm ---@MortenMacFly
Does this crash happen on the batch parse stage?

--- End quote ---
I don't know to be honest. It could be that it happens when I close C::B quickly (and parsing did not complete). I'll try to pay attention to this.

seb_seb0:
Hi,

I have found the exact cause (of my parsing bug), and I have done a minimal project.
As OllyDbg said in his last post, this is a problem with namespace scope resolution.

See the Workspace attached.
Inside, you have 2 projects: a lib and an executable (no need to compile anything).
The lib is encapsulated in a namespace LIB_NS
In the executable, you have: main.h and main.cpp

In main.h, you have only 2 lines:

--- Code: ---#include "lib.h"

using namespace LIB_NS; //this line can cause trouble

--- End code ---

when the "using namespace" clause is defined in the header file, the bug occurs.
The bug does NOT occur when:
    1 - the using namespace clause is the cpp file
    2 - an explicit scope resolution is done in the source (ex: LIB_NS:: )

I hope this helps.
Best regards,

Sebastien

[attachment deleted by admin]

Navigation

[0] Message Index

[#] Next page

[*] Previous page