So, I have tried different settings:
max parser = 1: the problem is not corrected , even after waiting 20 minutes. Even worse, Code::Blocks crashes (I forgot to copy a RPT file from my work computer. However, the crash occured when I switched files in the editor by clicking on a tab. The RPT shows several calls to codecompletion::onplugindetach (do not remember the exact name).
max parser = 2 : same as for max parser = 5 (my default setting)
max parser = 10 : no improvement as well
I have noticed as well several things that may help you:
1 - the symbol browser displays all symbols, and when I use it to jump to declaration or implementation of a method, it works all the time (yeah !)
When I said "list" in my original post, I was speaking about the popup list appearing while typing
2 - the failure occurs only when I use the context menu in the editor, and selecting "Find Declaration" or "Find Implementation". I get the message "Not found : function name"
3 - the problem occurs for derived class from pure virtual class (A is virtual and declares the interface, B derives from A and implements the interface.)
Consider this:
class A
{
public:
A();
~A();
virtual void DoSomething(void) = 0; //interface
};
class B : public class A
{
public:
B();
~B();
virtual void DoSomething(void) {}; //implementation
};
void AFunction(A* pPointer)
{
pPointer->DoSomething(); //no tooltip here, no suggestion when typing "->", no parameter lists
};
4 - all my classes are defined in a namespace. In the symbol browser, if I select "View all local symbols (workspace)", only symbols from the active project appear, even if I select "1 parser" or "force 1 parser per workspace"
If I select "everything", then all symbols appear, including the one defined in my libs.
I hope it will help you to solve the problem.
Sebastien
EDIT: I still cannot get a minimal example workspace displaying the problem. There is probably a problem of too many symbols, or there is a function somewhere which break the codecompletion. I will try to simplify my workspace and see if I can narrow down the problem to a manageable size
Ollydbg, you should put A, B, AFunction in different projects.
it works fine.
I just got some time to separate "A", "B", and "AFunction" in three cbp, and only allow one tokenstree for the whole workspace.
And I can have "DoSomething" in the auto suggestion list after "pPointer->". :D
Yes, for simple projects, it works. But for my project, it fails, and I cannot pinpoint the problem yet. Give me a bit of time, and I will post you a minimal test case. The code I have posted is a typical case where it fails (implementation of a virtual interface, and calling it from somewhere else)
Thanks for the help.
BTW, here is a crash dump which occurs when max parsers thread are set to 1:
D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe caused an Access Violation at location 65f12fae in module D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll Reading from location 00000000.
Registers:
eax=00000000 ebx=00000000 ecx=0000006d edx=00000000 esi=00000312 edi=0241b120
eip=65f12fae esp=0022eed8 ebp=0022eed8 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
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
65ED7F8E D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65ED7F8E
65EC1B27 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65EC1B27
65EC071E D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65EC071E
65EAADBE D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65EAADBE
65F0A614 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\share\codeblocks\plugins\codecompletion.dll:65F0A614 _ZN12cbToolPlugin9BuildMenuEP9wxMenuBar
618744D0 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.dll:618744D0 _ZN7Manager12ProcessEventER15CodeBlocksEvent
6188B20C D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.dll:6188B20C _ZN13PluginManager13NotifyPluginsER15CodeBlocksEvent
618A911E D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.dll:618A911E _ZN14ProjectManager10SetProjectEP9cbProjectb
618B998A D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.dll:618B998A _ZN14ProjectManager19EndLoadingWorkspaceEv
618AE517 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.dll:618AE517 _ZN14ProjectManager13LoadWorkspaceERK8wxString
0042C476 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:0042C476
0042FDC5 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:0042FDC5
6CCC7670 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCC7670 _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
6CCC77A9 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCC77A9 _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
6CCC7B74 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCC7B74 _ZN12wxEvtHandler12ProcessEventER7wxEvent
6CCC7528 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCC7528 _ZN12wxEvtHandler20ProcessPendingEventsEv
6CC417AE D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CC417AE _ZN12wxAppConsole20ProcessPendingEventsEv
6D05E549 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6D05E549 _ZN18wxIconLocationBaseC2ERK8wxString
7E42B372 C:\WINNT\system32\USER32.dll:7E42B372 MoveWindow
7E42B317 C:\WINNT\system32\USER32.dll:7E42B317 MoveWindow
7E4278D0 C:\WINNT\system32\USER32.dll:7E4278D0 GetWindowTextLengthW
7C90E473 C:\WINNT\system32\ntdll.dll:7C90E473 KiUserCallbackDispatcher
6CCF569A D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCF569A _ZN11wxEventLoop8DispatchEv
6CD8D518 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CD8D518 _ZN17wxEventLoopManual3RunEv
6CD6BB19 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CD6BB19 _ZN9wxAppBase8MainLoopEv
004058C4 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:004058C4
6CC73248 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CC73248 _Z14wxUninitializev
6CCCD392 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCCD392 _Z7wxEntryP11HINSTANCE__S0_Pci
00401D71 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:00401D71
004627C6 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:004627C6
004010DB D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:004010DB
00401158 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:00401158
7C817077 C:\WINNT\system32\kernel32.dll:7C817077 RegisterWaitForInputIdle
-------------------
Error occured on Wednesday, May 4, 2011 at 10:50:15.
D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe caused an Access Violation at location 7c919af2 in module C:\WINNT\system32\ntdll.dll Writing to location 00000146.
Registers:
eax=00000136 ebx=00000000 ecx=0000036c edx=01326250 esi=01326240 edi=00000000
eip=7c919af2 esp=0022f8e4 ebp=0022f958 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
Call stack:
7C919AF2 C:\WINNT\system32\ntdll.dll:7C919AF2 RtlpWaitForCriticalSection
7C901046 C:\WINNT\system32\ntdll.dll:7C901046 RtlEnterCriticalSection
6CCC7566 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCC7566 _ZN12wxEvtHandler20ProcessPendingEventsEv
6CC417AE D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CC417AE _ZN12wxAppConsole20ProcessPendingEventsEv
6D05E549 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6D05E549 _ZN18wxIconLocationBaseC2ERK8wxString
7E42B372 C:\WINNT\system32\USER32.dll:7E42B372 MoveWindow
7E42B317 C:\WINNT\system32\USER32.dll:7E42B317 MoveWindow
7E4278D0 C:\WINNT\system32\USER32.dll:7E4278D0 GetWindowTextLengthW
7C90E473 C:\WINNT\system32\ntdll.dll:7C90E473 KiUserCallbackDispatcher
6CCF569A D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCF569A _ZN11wxEventLoop8DispatchEv
6CD8D518 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CD8D518 _ZN17wxEventLoopManual3RunEv
6CD6BB19 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CD6BB19 _ZN9wxAppBase8MainLoopEv
004058C4 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:004058C4
6CC73248 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CC73248 _Z14wxUninitializev
6CCCD392 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\wxmsw28u_gcc_cb.dll:6CCCD392 _Z7wxEntryP11HINSTANCE__S0_Pci
00401D71 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:00401D71
004627C6 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:004627C6
004010DB D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:004010DB
00401158 D:\WORK\03_MISSIONS\00_SDK\IDE\CODEBLOCKS\codeblocks.exe:00401158
7C817077 C:\WINNT\system32\kernel32.dll:7C817077 RegisterWaitForInputIdle
Sebastien
There are actually two bugs here:
1.) If a parser fails CC should not completely be broken, or at least this parser should be able to re-start / invalidate.
2.) The actual error might be caused by a parser bug, but I do have my doubts here as it sometimes works!
How does a parser know itself get failed? We say a parser get failed mostly because it exit DoParse() function too early, or internally it just Skip to the EOF.
I guess mostly the bug was caused by not correctly beginning search scopes.
e.g.
...
using namespace std;
...
vector<int> a;
If we try to resolve the "type" of the variable "a", we need to resolve the type string "vector < int >". Then the first step was try to resolve the string "vector". But if "std" is not in the beginning search scope, then we may failed in resolving the "vector" type. :D. This is my guess until a test code to reproduce it.
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:
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. :-(
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:
#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]