windows 7
cb night build svn 6931
my project have a cpp file named "data_space_helper.cpp/.h"
after open this cpp file do nothing 3~4 sec, the c::b crash.
OR, do the "Find declaration of FlowRuntimeContext",c::b crash.
do the same operator with other cpp files, OR, "Find declaration of XXX " (XXX isnot "FlowRuntimeContext"), everything ok, the c::b didn't crash.
---------
codeblocks.RPT is :
-------------------
Error occured on Sunday, January 23, 2011 at 01:15:45.
E:\CodeBlocks\codeblocks.exe caused an Access Violation at location 6d8e20f5 in module E:\CodeBlocks\share\codeblocks\plugins\debugger.dll Reading from location fffffff8.
Registers:
eax=fffffff4 ebx=00000000 ecx=00000001 edx=00000000 esi=000006a9 edi=0211ee00
eip=6d8e20f5 esp=0022f3b8 ebp=0022f3bc iopl=0 nv up ei ng nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010293
Call stack:
6D8E20F5 E:\CodeBlocks\share\codeblocks\plugins\debugger.dll:6D8E20F5 _ZN8cbPlugin9OnReleaseEb
6D8E20DD E:\CodeBlocks\share\codeblocks\plugins\debugger.dll:6D8E20DD _ZN8cbPlugin9OnReleaseEb
6D8E2CF5 E:\CodeBlocks\share\codeblocks\plugins\debugger.dll:6D8E2CF5 _ZNK8cbPlugin9CanDetachEv
6D8D880D E:\CodeBlocks\share\codeblocks\plugins\debugger.dll:6D8D880D _ZN14cbWizardPlugin9BuildMenuEP9wxMenuBar
6D8B5EF6 E:\CodeBlocks\share\codeblocks\plugins\debugger.dll:6D8B5EF6
6D898C2E E:\CodeBlocks\share\codeblocks\plugins\debugger.dll:6D898C2E
6D89BA42 E:\CodeBlocks\share\codeblocks\plugins\debugger.dll:6D89BA42
6CCC3C28 E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCC3C28 _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
6CCC3D61 E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCC3D61 _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
6CCC412C E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCC412C _ZN12wxEvtHandler12ProcessEventER7wxEvent
6CCC3AC0 E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCC3AC0 _ZN12wxEvtHandler20ProcessPendingEventsEv
6CC417AE E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CC417AE _ZN12wxAppConsole20ProcessPendingEventsEv
6D0372ED E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6D0372ED _ZN18wxIconLocationBaseC2ERK8wxString
76F27B45 C:\Windows\system32\USER32.dll:76F27B45 GetUserObjectInformationA
76F331EB C:\Windows\system32\USER32.dll:76F331EB GetClassNameW
76F34260 C:\Windows\system32\USER32.dll:76F34260 ChangeWindowMessageFilter
779A647E C:\Windows\SYSTEM32\ntdll.dll:779A647E KiUserCallbackDispatcher
6CCF0A7E E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCF0A7E _ZN11wxEventLoop8DispatchEv
6CD84A6C E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CD84A6C _ZN17wxEventLoopManual3RunEv
6CD64279 E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CD64279 _ZN9wxAppBase8MainLoopEv
004058C4 E:\CodeBlocks\codeblocks.exe:004058C4
6CC7114E E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CC7114E _Z14wxEntryCleanupv
6CCC95D6 E:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCC95D6 _Z7wxEntryP11HINSTANCE__S0_Pci
00401D71 E:\CodeBlocks\codeblocks.exe:00401D71
0045F7F6 E:\CodeBlocks\codeblocks.exe:0045F7F6
004010DB E:\CodeBlocks\codeblocks.exe:004010DB
00401158 E:\CodeBlocks\codeblocks.exe:00401158
77661194 C:\Windows\system32\kernel32.dll:77661194 BaseThreadInitThunk
779BB529 C:\Windows\SYSTEM32\ntdll.dll:779BB529 RtlInitializeExceptionChain
779BB4FC C:\Windows\SYSTEM32\ntdll.dll:779BB4FC RtlInitializeExceptionChain
==============================
add :
back to svn 6921 : occurred yet.
back to svn 6906 : occurred yet...
back to 10.02 : now, not occurred. :)
sorry for my english.
@nanyu
please supply at least the test code that we can help to test the CC crash. (you can send me email also)
I have send this project to your gmail. thanks.
I found the bug, here is a simple test case I just create for test:
namespace CollaGEN
{
namespace Engine
{
using namespace std;
using namespace Flowscript;
using namespace Dataspace;
using namespace Flowparser;
using namespace Flowdata;
int aaa;
}
}
The bug is here: parserthread.cpp line 677 changed in rev 6306 by morten (applying a patch from who? I do not know)
}
else if (token==ParserConsts::kw_using)
{
wxString peek = m_Tokenizer.PeekToken();
if (peek == ParserConsts::kw_namespace)
{
// ok
m_Tokenizer.GetToken(); // eat namespace
while (true) // support full namespaces
{
m_Str << m_Tokenizer.GetToken();
if (m_Tokenizer.PeekToken() == ParserConsts::dcolon)
m_Str << m_Tokenizer.GetToken();
else
break;
}
if ((!m_Str.IsEmpty())
&& m_pLastParent != 0L
&& (m_pLastParent->GetSelf() != -1)
&& (m_pLastParent->m_TokenKind == tkNamespace ) )
{
if(m_pLastParent->m_AncestorsString.IsEmpty())
m_pLastParent->m_AncestorsString<<m_Str;
else
m_pLastParent->m_AncestorsString<<_T(',')<<m_Str;
}
}
else
SkipToOneOfChars(ParserConsts::semicolonclbrace);
m_Str.Clear();
}
The old code was just like: rev 6302
else if (token == ParserConsts::kw_using) // using namespace ?
{
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
m_Str.Clear();
}
The wrong thing is:
std
Flowscript
Dataspace
Flowparser
Flowdata
all these items will be mistakenly add to Engine's m_AncestorsString , this is totally wrong.
The one made this patch will have a review. And simply revert this code to rev 6302 I think can fix this issue.
I found the bug, here is a simple test case I just create for test:
The bug is here: parserthread.cpp line 677 changed in rev 6306 by morten (applying a patch from who? I do not know)
......
The wrong thing is:
std
Flowscript
Dataspace
Flowparser
Flowdata
all these items will be mistakenly add to Engine's m_AncestorsString , this is totally wrong.
The one made this patch will have a review. And simply revert this code to rev 6302 I think can fix this issue.
Is this error make my c::b crash?
Same question: why lead cb crash?
The rev6306 likes for resoved this issue:
#include <vector>
namespace CollaGEN
{
using namespace std;
namespace Engine
{
using namespace std;
int aaa;
}
}
int main()
{
CollaGEN::Engine::vector<int> v;
CollaGEN::vector<float> vf;
return 0;
}
Same question: why lead cb crash?
void TokensTree::RecalcInheritanceChain(Token* token)
will be called endless.
Here is the candidate patch to solve the crash bug.
[...]
my patch just avoid the endless loop and crash.
Mmmh... why don't you simply do a:
wxStringTokenizer tkz(token->m_AncestorsString, _T(","));
token->m_AncestorsString.Clear();
if (!token->m_IsLocal) // global symbols are linked once
{
//Manager::Get()->GetMessageManager()->DebugLog("Removing ancestor string from %s", token->m_Name.c_str(), token->m_Name.c_str());
token->m_AncestorsString.Clear();
}
rickg22 2006-1-11 15:19:20
Revamped the CodeCompletion plugin, Stage 1. Reparsing after saving files is much faster now. Also, the code completion functionality is much faster due to the searchtree structure.
Known issues: The Class browser is NOT updated when using the cache. WARNING: Might cause crashes if you have the cache enabled. Please disable it.
I'm not sure why a token with m_IsLocal==true does NOT allowed to remove the m_AncestorsString. But currently rick is not maintain the CC's code, So I guess he nearly forget something. I'll PM him about this.
From my point of view, there is no reason we should keep the ancestorstring if we already use it to calculate the hierarchy. :D
see the source code:
void TokensTree::RecalcData()
{
#if CC_TOKEN_DEBUG_OUTPUT
wxStopWatch sw;
#endif
TRACE(_T("RecalcData() : Calculating full inheritance tree."));
// first loop to convert ancestors string to token indices for each token
for (size_t i = 0; i < size(); ++i)
{
Token* token = at(i);
if (!token)
continue;
if (!(token->m_TokenKind & (tkClass | tkTypedef | tkEnum | tkNamespace)))
continue;
if (token->m_AncestorsString.IsEmpty())
continue;
// only local symbols might change inheritance
// if (!token->m_IsLocal)
// continue;
the last two line was comment out in rev 2855 by mandrav.
Note: currently, the function RecalcData() is not used in CC. we use a new method to dynamically call the hierarchy. which is:
class A :public B,C{};
class D :public B,C{};
class C :public X{};
Once the parser finish parsing, then, A's ancestorString is "B,C", D's ancestorString is "B,C", and C's ancestorString is "X".
Now, every thing is OK, we do not call RecalcData(). What's RecalcData() does can divided to two stages:
1, transform the ancestorString to ancestor Idx on evey tokens of the tree. so, A's ancestorIdx will have index to Token B, and index C
D's ancestorIdx will have index to Token B, and index C ; D's ancestorIdx will have index to Token X. no further hierarchy is calculated. meanwhile, all the ancestorString will be cleared.(as they were transform to Idxs)
2, calculate the full hierarchy, which means a recursive function call:
A's ancestorIdx will have index to Token B, Token C and Token X. (Token X added by calculate the hierarchy)
D's ancestorIdx will have index to Token B, and Token C and Token X. (Token X added by calculate the hierarchy)
C's ancestorIdx will have index to Token X. (the same as stage 1)
The currently way we use was "calculate the fully hierarchy on the Tokens we would like to use". which means if we want to query information of Token A, we only calculate the "stage 1 and stage 2" on the exact token A.
BTW:
This thread was suggested to move to CC's sub forum to record such info. :D
patch v2.
Index: token.cpp
===================================================================
--- token.cpp (revision 7028)
+++ token.cpp (working copy)
@@ -1039,8 +1039,12 @@
TRACE(_T("RecalcInheritanceChain() : Token %s, Ancestors %s"), token->m_Name.wx_str(),
token->m_AncestorsString.wx_str());
-
wxStringTokenizer tkz(token->m_AncestorsString, _T(","));
+
+ TRACE(_T("RecalcInheritanceChain() : Removing ancestor string from %s"), token->m_Name.wx_str());
+ token->m_AncestorsString.Clear();
+
+
while (tkz.HasMoreTokens())
{
wxString ancestor = tkz.GetNextToken();
@@ -1111,11 +1115,6 @@
token->m_DirectAncestors = token->m_Ancestors;
- if (!token->m_IsLocal) // global symbols are linked once
- {
- TRACE(_T("RecalcInheritanceChain() : Removing ancestor string from %s"), token->m_Name.wx_str());
- token->m_AncestorsString.Clear();
- }
}
#if CC_TOKEN_DEBUG_OUTPUT