Is CC crash, or Debugger plugin?

[oBFusCATed]

And one infinite loop here:

Code

Program received signal SIGINT, Interrupt.
0x00002ba5dfa6607c 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
922               __x = __comp ? _S_left(__x) : _S_right(__x);
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
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
922               __x = __comp ? _S_left(__x) : _S_right(__x);
(gdb) bt
#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
#8  0x00002aaab4bc57b4 in NativeParser::ParseLocalBlock (this=0x1c349e00, searchData=0x7fff30d2fd20, caretPos=13770) at nativeparser.cpp:1563
#9  0x00002aaab4bc6420 in NativeParser::MarkItemsByAI (this=0x1c349e00, searchData=0x7fff30d2fd20, result=std::set with 0 elements, reallyUseAI=true, isPrefix=false, caseSensitive=true, caretPos=13770) at nativeparser.cpp:1693
#10 0x00002aaab4bc6712 in NativeParser::MarkItemsByAI (this=0x1c349e00, result=std::set with 0 elements, reallyUseAI=true, isPrefix=false, caseSensitive=true, caretPos=13770) at nativeparser.cpp:1659
#11 0x00002aaab4b945d7 in CodeCompletion::OnValueTooltip (this=0x1c349d80, event=...) at codecompletion.cpp:2498
#12 0x00002aaab4ba869f in cbEventFunctor<CodeCompletion, CodeBlocksEvent>::Call (this=0x1ca9ab30, event=...) at ../../../src/include/cbfunctor.h:35
#13 0x00002ba5dfaa8f42 in Manager::ProcessEvent (this=0x1b7246a0, event=...) at manager.cpp:174
#14 0x00002ba5dfabd6a9 in PluginManager::NotifyPlugins (this=0x1bfeb680, event=...) at pluginmanager.cpp:1474
#15 0x00002ba5df9d7700 in cbEditor::NotifyPlugins (this=0x1cf05640, type=10354, intArg=11, strArg=..., xArg=372, yArg=554) at cbeditor.cpp:802
#16 0x00002ba5df9d79c0 in cbEditor::OnEditorDwellStart (this=0x1cf05640, event=...) at cbeditor.cpp:3382
#17 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#18 0x0000003744cfce12 in wxEvtHandler::SearchDynamicEventTable (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1421
#19 0x0000003744cfcec2 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1297
#20 0x0000003747af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#21 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#22 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#23 0x00002ba5dfbe524a in wxScintilla::NotifyParent (this=0x1ceff860, _scn=0x7fff30d30440) at src/wxscintilla.cpp:4968
#24 0x00002ba5dfbdb7b4 in ScintillaWX::NotifyParent (this=0x1cf0c850, scn=...) at src/ScintillaWX.cpp:520
#25 0x00002ba5dfc8f377 in Editor::NotifyDwelling (this=0x1cf0c850, pt=..., state=true) at src/scintilla/src/Editor.cxx:4325
#26 0x00002ba5dfc95b33 in Editor::Tick (this=0x1cf0c850) at src/scintilla/src/Editor.cxx:6383
#27 0x00002ba5dfbdd233 in ScintillaWX::DoTick (this=0x1cf0c850) at src/ScintillaWX.h:159
#28 0x00002ba5dfbdd24f in wxSCITimer::Notify (this=0x1cf2acb0) at src/ScintillaWX.cpp:48
#29 0x00000037479ed2e3 in timeout_callback (data=<value optimized out>) at ./src/gtk/timer.cpp:45
#30 0x000000373ee2d2bb in ?? () from /lib64/libglib-2.0.so.0
#31 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#32 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#33 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#34 0x000000374232aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#35 0x00000037479e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#36 0x0000003747a72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#37 0x0000000000448d0a in CodeBlocksApp::OnRun (this=0x1b683050) at app.cpp:788
#38 0x0000003744c99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#39 0x000000000044c7bc in main (argc=1, argv=0x7fff30d309a8) at app.cpp:260

I guess there is some memory corruption happening somewhere, because a bug in std::set is highly unlikely.
Loaden any thoughts or ideas?
I don't have time to debug it with valgrind unfortunately?

Is it possible to run the parser test application on a whole workspace (something like "parser_test --workspace my.workspace"), because C::B is hard to debug in valgrind?

p.s. This happens on a relatively simple project! But I'm not allowed to share it and it is pretty random.
p.p.s. This happens at least once per day for me!

Edit: this is on the latest debugger branch and Centos 5.6 amd64

[ollydbg]

looking at the call-stack, I think that it does not happened on the batch parse stage.
because there is a function call:

CodeCompletion::OnValueTooltip

So, this crash happens when user hover on the editor.

[oBFusCATed]

Yes, but checking the parser with valgrind won't hurt
If the parser test could parse whole projects/workspaces I can invest some time to see if there are any problems.

[ollydbg]

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

PS: As OBF's crash call stack was in debugger branch, so I only review cc's code in this branch. (not trunk).

[Loaden]

I guess there is some memory corruption happening somewhere, because a bug in std::set is highly unlikely.
Loaden any thoughts or ideas?

Please try rev7281.

[ollydbg]

I guess there is some memory corruption happening somewhere, because a bug in std::set is highly unlikely.
Loaden any thoughts or ideas?

Please try rev7281.

@loaden:

the latest debugger branch rev 7276 and the trunk 7281 is nearly the same.

[Loaden]

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

PS: As OBF's crash call stack was in debugger branch, so I only review cc's code in this branch. (not trunk).

Code

size_t NativeParser::MarkItemsByAI(ccSearchData* searchData, TokenIdxSet& result, bool reallyUseAI, bool isPrefix,
                                   bool caseSensitive, int caretPos)
{
    wxCriticalSectionLocker locker(s_TokensTreeCritical);
    result.clear();

The locker added here.

[ollydbg]

Code

size_t NativeParser::MarkItemsByAI(ccSearchData* searchData, TokenIdxSet& result, bool reallyUseAI, bool isPrefix,
                                   bool caseSensitive, int caretPos)
{
    wxCriticalSectionLocker locker(s_TokensTreeCritical);
    result.clear();

The locker added here.

Oh, that's my mistake... the crash reason is still unknown...

[oBFusCATed]

Does the parser test project work on linux?
For me it crashes badly on strange places

[ollydbg]

Does the parser test project work on linux?
For me it crashes badly on strange places

So, you use the "parsertest-unix.cbp", that file is exacted to work. but mostly I'm using the "parsertest.cbp" under Windows.

what's the crash traceback?

Maybe, you can ask Loaden to test the linux parser test project.

[ollydbg]

#7  0x00002aaab4be108d in Parser::ParseBuffer (this=0x1cf23830, buffer=..., isLocal=false, bufferSkipBlocks=false, isTemp=true, filename=..., parent=0x2aaaac468a70, initLine=0) at parser/parser.cpp:450

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

[ollydbg]

#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

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;

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]

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

PS: As OBF's crash call stack was in debugger branch, so I only review cc's code in this branch. (not trunk).

Code

size_t NativeParser::MarkItemsByAI(ccSearchData* searchData, TokenIdxSet& result, bool reallyUseAI, bool isPrefix,
                                   bool caseSensitive, int caretPos)
{
    wxCriticalSectionLocker locker(s_TokensTreeCritical);
    result.clear();

The locker added here.

@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();
}

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]

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;

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.

A fatal mistake!
Thanks for report! Your are hero!!