Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Is CC crash, or Debugger plugin?
ollydbg:
--- Quote ---#7 0x00002aaab4be108d in Parser::ParseBuffer (this=0x1cf23830, buffer=..., isLocal=false, bufferSkipBlocks=false, isTemp=true, filename=..., parent=0x2aaaac468a70, initLine=0) at parser/parser.cpp:450
--- End quote ---
I just review the crash report, and think that initLine=0, this are potential logic error, because basically there is no such function implementation which its implementation start line number 0.
I guess such situation is that this function does not have implementation, and it just has a declaration. so, the m_ImplLineStart value is 0 as it initialized by the Token's constructor.
Any ideas?
Edit:
@OBF
Why the value "filename=...", can I see the true value, I don't want to see the "..." :D.
ollydbg:
--- Quote ---#0 0x00002ba5dfa660a7 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::insert_unique (this=0x2aaaac468ad0, __v=@0x7fff30d2f474)
at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:922
#1 0x00002ba5dfa66241 in std::set<int, std::less<int>, std::allocator<int> >::insert (this=0x2aaaac468ad0, __x=@0x7fff30d2f474) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_set.h:321
#2 0x00002aaab4bfa9d6 in Token::AddChild (this=0x2aaaac468a70, childIdx=6207) at parser/token.cpp:348
#3 0x00002aaab4bf0fbe in ParserThread::DoAddToken (this=0x1d4b7540, kind=tkVariable, name=..., line=3, implLineStart=0, implLineEnd=0, args=..., isOperator=false, isImpl=false) at parser/parserthread.cpp:1279
#4 0x00002aaab4bf4c29 in ParserThread::DoParse (this=0x1d4b7540) at parser/parserthread.cpp:1031
#5 0x00002aaab4bf789b in ParserThread::Parse (this=0x1d4b7540) at parser/parserthread.cpp:481
#6 0x00002aaab4be0c42 in Parser::Parse (this=0x1cf23830, bufferOrFilename=..., isLocal=false, opts=...) at parser/parser.cpp:553
#7 0x00002aaab4be108d in Parser::ParseBuffer (this=0x1cf23830, buffer=..., isLocal=false, bufferSkipBlocks=false, isTemp=true, filename=..., parent=0x2aaaac468a70, initLine=0) at parser/parser.cpp:450
--- End quote ---
here, we are trying to add a child index (an int value) to the parent Token, which has the address "0x2aaaac468a70", so next time if it crashed, I would like to do some sanity check on this Token. This Token is expect to be a function Token.
ollydbg:
I'm very surprised that why the critical section object is defined in the header file?
see: token.h
--- Code: ---// Make sure already entered a critical section if TokensTree related!
static wxCriticalSection s_TokensTreeCritical;
--- End code ---
This means if two cpp files were include token.h, then the result is there are two critical sections for each cpp file.
Does that logical OK?
I found that there are many statement like "wxCriticalSectionLocker locker(s_TokensTreeCritical);"
in many cpp files. which means we have many critical section objects.
ollydbg:
--- Quote from: Loaden on July 09, 2011, 11:49:28 am ---
--- Quote from: ollydbg on July 09, 2011, 09:24:50 am ---@loaden:
I just look at the crash call stack OBF posted, I found that
Do we need to do the "parser“ and "TokensTree" locking when we are calling function ParseBuffer()?
It seems that I can't find any lockers in the call function chain. so, it seems the shared resource was not protected. :D
PS: As OBF's crash call stack was in debugger branch, so I only review cc's code in this branch. (not trunk).
--- End quote ---
--- Code: ---size_t NativeParser::MarkItemsByAI(ccSearchData* searchData, TokenIdxSet& result, bool reallyUseAI, bool isPrefix,
bool caseSensitive, int caretPos)
{
wxCriticalSectionLocker locker(s_TokensTreeCritical);
result.clear();
--- End code ---
The locker added here.
--- End quote ---
@loaden:
since my previous post, that the code above means:
enter the critical section s_TokensTreeCritical belongs the cpp file "NativeParser.cpp", so I guess that other files' access to TokensTree is still not protected.
Is this the designed behavior?
here comes another issue
look at the code:
--- Code: ---Parser::Parser(wxEvtHandler* parent, cbProject* project) :
m_Parent(parent),
m_Project(project),
m_UsingCache(false),
m_Pool(this, wxNewId(), 1, 2 * 1024 * 1024), // in the meanwhile it'll have to be forced to 1
m_IsPriority(false),
m_NeedsReparse(false),
m_IsFirstBatch(false),
m_IsParsing(false),
m_Timer(this, TIMER_ID),
m_BatchTimer(this, BATCH_TIMER_ID),
m_StopWatchRunning(false),
m_LastStopWatchTime(0),
m_IgnoreThreadEvents(true),
m_IsBatchParseDone(false),
m_ParsingType(ptCreateParser),
m_NeedMarkFileAsLocal(true)
{
m_TokensTree = new TokensTree;
m_TempTokensTree = new TokensTree;
ReadOptions();
ConnectEvents();
}
--- End code ---
If you have two Parser object, so you have two TokensTree. (ignore the temp tokens tree).
It is very safe that both tree can access simultaneously, and we don't need to use critical section in this case.
As our current implementation will totally block the above case.
So, I think the critical section should be bundled to Parser object(e.g. as it's member variable), and not bundled to the cpp file scope.
any ideas?
Loaden:
--- Quote from: ollydbg on July 14, 2011, 05:08:40 am ---I'm very surprised that why the critical section object is defined in the header file?
see: token.h
--- Code: ---// Make sure already entered a critical section if TokensTree related!
static wxCriticalSection s_TokensTreeCritical;
--- End code ---
This means if two cpp files were include token.h, then the result is there are two critical sections for each cpp file.
Does that logical OK?
I found that there are many statement like "wxCriticalSectionLocker locker(s_TokensTreeCritical);"
in many cpp files. which means we have many critical section objects.
--- End quote ---
A fatal mistake!
Thanks for report! Your are hero!!
:D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version