Code Completion & Workspace

[ollydbg]

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

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]

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?

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

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

@MortenMacFly
Does this crash happen on the batch parse stage?

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

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]

[seb_seb0]

In the 1st image, consider the virtual class L3D_IRenderSystem.
L3D_IRenderSystem is defined in the lib, and I use a pointer to it in the main program.
I can see it in the symbol browser, but when I right click on "Find the Declaration of : 'L3D_IRenderSystem'", I get the error message "Not found ..."

"Find the Declaration" is just doing a scope match. I wrote this in the wiki, see:
6 Automatic Code Completion

and about debugging cc plugin, there are two kind of tracer
1, if you want to debug the parser, you can simply follow this:
7 Code completion debugging support

2, if you want to see how "find the declaration works", you should enable the
7.4 Debug Smart Sense log output
Note that CC does not do "full preprocessor" and "type check", so it may failed in parsing something. But if the parser is running endlessly, it mostly has a infinite loop bug, this bug should be fixed.

Thanks for the info, I will use it, and I will let you know if I find something.
To sum up what has been said, there are 3 bugs :
   1 - a problem with namespace scope resolution - see my last post with a minimal test project
   2 - a problem of Parser Thread blocked in an endless loop => I will try to see what I can find
   3 - a crash problem : for me, it occured when switching to another opened file, by clicking on an editor tab (that means several files are opened).
                                   It did not occured while trying to quit CB.

On the bright side: since the bugs are identified, we can solve them !

Sebastien

[killerbot]

when the "using namespace" clause is defined in the header file, the bug occurs.

CC should not fail on that. Agreed, but the only advice I can give you : just don't do this. That is not the intention of namespaces, actually this is killing the entire purpose of namespaces .
See also books of Meyers, Sutter, ...

[ollydbg]

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

True, the current implementation has this bug. Mostly because we do NOT expand the #include directive.
In-fact, we have very limited preprocessor directive handling.

We only collect the "using namespace xxx" directive in the current file. So, as you said, if the "using namespace clause" was in other header files, surely they will be ignored, and this bug will occur.

see:6.1 Find the search scope, I have explained the method on how to correct a initial search scope.

BTW: If we do a full preprocessor handling, we are nearly design a full compiler front end.

[MortenMacFly]

  2 - a problem of Parser Thread blocked in an endless loop => I will try to see what I can find

I finally have a test case for this.

In the attached project, if you inspect the log it never stop parsing the second project. You have to ensure, that you have *one* parser for the whole workspace to reproduce. Notice that both projects are the same, except that the second one compiles/links statically. Thu they use different #defines, but for the same sources (wx). Maybe that's the issue - reminds me to try what happens if I disable the complex macro parsing...

[ollydbg]

  2 - a problem of Parser Thread blocked in an endless loop => I will try to see what I can find

I finally have a test case for this.

In the attached project, if you inspect the log it never stop parsing the second project. You have to ensure, that you have *one* parser for the whole workspace to reproduce. Notice that both projects are the same, except that the second one compiles/links statically. Thu they use different #defines, but for the same sources (wx). Maybe that's the issue - reminds me to try what happens if I disable the complex macro parsing...

the attachment zip file has not cpp files in it? did you forget attach them?

[MortenMacFly]

the attachment zip file has not cpp files in it? did you forget attach them?

No, that is on purpose. It's enough, if CC tries to parse the "up-front" headers (wx in this case).

[ollydbg]

Here is the log in my PC:

Loading workspace "F:\cb\test_code\Demo\Demo.workspace"
Loading project file...
Parsing project file...
Loading target default
Loading project files...
1 files loaded
Done loading project in 31ms
Project's base path: F:\cb\test_code\Demo\
Project's common toplevel path: F:\cb\test_code\Demo\
Loading project file...
Parsing project file...
Loading target default
Loading project files...
1 files loaded
Done loading project in 0ms
Project's base path: F:\cb\test_code\Demo\
Project's common toplevel path: F:\cb\test_code\Demo\
Caching GCC dir: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include\c++
Caching GCC dir: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include\c++\i686-pc-mingw32
Caching GCC dir: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include\c++\backward
Caching GCC dir: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\include
Caching GCC dir: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include
Caching GCC dir: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include-fixed
Caching GCC dir: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\i686-pc-mingw32\include
Passing list of files to batch-parser.
Header to parse up-front: 'D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include\c++\cstddef'
Header to parse up-front: 'D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\i686-pc-mingw32\include\w32api.h'
Header to parse up-front: 'D:\code\wxWidgets-2.8.12\include\wx\defs.h'
Header to parse up-front: 'D:\code\wxWidgets-2.8.12\include\wx\dlimpexp.h'
Header to parse up-front: 'D:\code\wxWidgets-2.8.12\include\wx\toplevel.h'
Add up-front parsing 5 file(s) for project 'Demo'...
Add batch-parsing 1 file(s) for project 'Demo'...
Create new parser for project 'Demo'
Starting batch parsing for project 'Demo'...
Project 'Demo' parsing stage done (141 total parsed files, 12725 tokens in 0 minute(s), 12.562 seconds).
Updating class browser...
Class browser updated.
Add project (Demo (static)) to parser
Get Headers: D:\code\wxWidgets-2.8.12\include\ , 688
Get Headers: D:\code\wxWidgets-2.8.12\lib\gcc_dll\mswu\ , 2
Get Headers: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include\c++\ , 611
Get Headers: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include\c++\i686-pc-mingw32\ , 23
Get Headers: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include\c++\backward\ , 8
Get Headers: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\include\ , 5
Get Headers: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include\ , 39
Get Headers: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\lib\gcc\i686-pc-mingw32\4.5.4\include-fixed\ , 3
Get Headers: D:\code\mingw_gcc4.5.4.20110428_static_win32\MinGW\i686-pc-mingw32\include\ , 1231
Get the system header file path: 9

looks like there should be a log saying that, but in-fact no such log message, that's strange.

Project 'Demo static' parsing stage done.....

edit: the CPU usage is quite low (<5%), it seems CC was not in a infinite loop.

[MortenMacFly]

edit: the CPU usage is quite low (<5%), it seems CC was not in a infinite loop.

It's not an "infinite loop" in a sense that it eats CPU. But it never returns and so all CC actions will report "parser still parsing files" forever.

IMHO the parser fails silently with an error and this is not handeled correctly.

[ollydbg]

It's not an "infinite loop" in a sense that it eats CPU. But it never returns and so all CC actions will report "parser still parsing files" forever.

IMHO the parser fails silently with an error and this is not handeled correctly.

Yes, I think I will take some time to trace the bug. (not right now ) I suspect that when batch parsing the second project, no parserthread object was created(all the necessary files were already parsed in the first project) and no files were put into the thread pool, so maybe the "End of batch parse Event" never triggered.

[Loaden]

The BUG maybe related with memory pool.
Please trying REV7122: "CC: Disable memory pool again, avoid possible crash".