Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => CodeCompletion redesign => Topic started by: Loaden on June 09, 2011, 08:09:51 am

Title: Is CC crash, or Debugger plugin?
Post by: Loaden on June 09, 2011, 08:09:51 am
Do you have the CC tooltips activated? Most of the time the crashes happen there.
Sometimes it happens, when I debug something, move the mouse over a variable and it crashes. Somewhere in AddToken.
It happens on complex projects: my work project, C::B debuggers branch. It is very rare crash, but it is quite annoying :(

Sometimes it happens, when I debug something, move the mouse over a variable and it crashes.
Do you enable the option: "Compiler and debugger settings > Debugger settings > Evaluate expression under cursor"  ?


Yes, I always have it enabled.

Somebody has same issue about this?
We need more information.
:)
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on June 09, 2011, 08:20:57 am
what is the exact steps to product the crash???
I don't have such crash when debugging, if the debugee crashed, you can at least see the debug-log message.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on June 09, 2011, 08:38:17 am
what is the exact steps to product the crash???
I don't have such crash when debugging, if the debugee crashed, you can at least see the debug-log message.
Hi, ollydbg, Do you remember the option: "Compiler and debugger settings > Debugger settings > Evaluate expression under cursor".
If use this option, there will random crash when debug any project.
So, you tell me, just shut off the option?
About A year ago... :D
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on June 09, 2011, 08:40:24 am
At that time, we are rewriting CC.
So, this issue should existed on Code::Blocks 10.5 official release.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on June 09, 2011, 08:50:17 am
I suggest you turn off that option "Compiler and debugger settings > Debugger settings > Evaluate expression under cursor", because when the mouse hover a variable which is not initialized.(e.g. an un-initialized std::vector), then gdb will crash. :D
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on June 09, 2011, 09:31:15 am
I suggest you turn off that option "Compiler and debugger settings > Debugger settings > Evaluate expression under cursor", because when the mouse hover a variable which is not initialized.(e.g. an un-initialized std::vector), then gdb will crash. :D
At the same time, CC doing buffer parsing for local variable.
And should add the token to the temp tokens-tree.
So, If you turn off the option, the crash should been gone.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on June 09, 2011, 10:20:20 am
Loaden: The debugger plugin runs in the main thread and has no access to the CC data structures.
The backtrace points to AddToken in the CC plugin, so it is definitely CC crash.
And this crash happens during code editing, too.

I'll give you the backtrace the next time it happens. At the moment I'm on linux debugger's branch head.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on June 09, 2011, 10:47:34 am
Loaden: The debugger plugin runs in the main thread and has no access to the CC data structures.
The backtrace points to AddToken in the CC plugin, so it is definitely CC crash.
And this crash happens during code editing, too.

I'll give you the backtrace the next time it happens. At the moment I'm on linux debugger's branch head.
In sometimes, I don't believe GDB's backtrace.
So, I am tried MSVC's Debugger, but CB can't compile with MSVC, or can't work.
In many times, the GDB's backtrace is not useful.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on June 09, 2011, 11:19:20 am
1. The backtrace is from the build in crash handler in C::B, not GDB.
2. GDB on linux is totally different beast to GDB on windows
3. The backtrace looks pretty normal, no strange things in it.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on June 09, 2011, 12:57:10 pm
1. The backtrace is from the build in crash handler in C::B, not GDB.
2. GDB on linux is totally different beast to GDB on windows
3. The backtrace looks pretty normal, no strange things in it.

OK, Please try the latest reversion, at least rev7188.
If you catch any thing, please post here.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on June 09, 2011, 01:11:13 pm
I'm on the branch and have to wait for the next merge.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on June 09, 2011, 01:26:23 pm
If I have such crash, I will report it here. :D
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on June 09, 2011, 04:46:13 pm
Crashed again, head of debugger's branch built with --enable-debug.
I've attached both a crash report generated by C::B and backtrace for all threads taken from gdb.

Happy debugging  8)
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on June 20, 2011, 05:56:42 pm
Loaden: The crash is not fixed with the locker changes you've made recently. I'm using debuggers branch r7245.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on June 30, 2011, 12:15:15 pm
And a deadlock here:

Code
(gdb) bt
#0  0x0000003afd60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x0000003afd608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x0000003afd608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003b954fa3e9 in wxMutexInternal::Lock (this=<value optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002aaab2eff2de in CodeCompletion::ParseFunctionsAndFillToolbar (this=0x1ad22d20, force=<value optimized out>) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x0000003b954fcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#6  0x0000003b954fcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#7  0x0000003b954fcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#8  0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#9  0x0000003b954fd3d0 in wxEvtHandler::ProcessPendingEvents (this=<value optimized out>) at ./src/common/event.cpp:1196
#10 0x0000003b9546214e in wxAppConsole::ProcessPendingEvents (this=<value optimized out>) at ./src/common/appbase.cpp:294
#11 0x0000003b90a723d6 in wxAppBase::ProcessIdle (this=<value optimized out>) at ./src/common/appcmn.cpp:435
#12 0x0000003b909cd99f in wxapp_idle_callback () at ./src/gtk/app.cpp:213
#13 0x0000003b9242cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#14 0x0000003b9242fc0d in ?? () from /lib64/libglib-2.0.so.0
#15 0x0000003b9242ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#16 0x0000003b958b88ca in gtk_dialog_run () from /usr/lib64/libgtk-x11-2.0.so.0
#17 0x0000003b90a5a7ba in wxMessageDialog::ShowModal (this=<value optimized out>) at ./src/gtk/msgdlg.cpp:117
#18 0x00002ac1b5e13228 in cbMessageBox (message=..., caption=..., style=256, parent=<value optimized out>, x=-1, y=-1) at globals.cpp:1219
#19 0x00002aaab2ef56f6 in CodeCompletion::OnGotoDeclaration (this=0x1ad22d20, event=...) at codecompletion.cpp:2800
#20 0x0000003b954fcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#21 0x0000003b954fcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#22 0x0000003b954fcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#23 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#24 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#25 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#26 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#27 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#28 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#29 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#30 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#31 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#32 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#33 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#34 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#35 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#36 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#37 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#38 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#39 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#40 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#41 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#42 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#43 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#44 0x0000003b90af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#45 0x0000003b954fce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#46 0x0000003b954fce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#47 0x0000003b90af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#48 0x0000003b954fce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#49 0x0000003b90af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#50 0x0000003b954fce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#51 0x00002aaab4ce42f4 in wxMenuCmd::Exec (this=<value optimized out>, origin=0x1b8b0fa0, client=0x1b8b0fa0) at menuutils.cpp:543
#52 0x00002aaab4cda9d2 in wxKeyBinder::OnChar (this=0x1b144070, event=..., next=0x1b8b0fa0) at keybinder.cpp:1429
#53 0x0000003b954fcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#54 0x0000003b954fcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#55 0x0000003b954fcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#56 0x0000003b909f8ef6 in gtk_window_key_press_callback (widget=<value optimized out>, gdk_event=<value optimized out>, win=<value optimized out>) at ./src/gtk/window.cpp:1034
#57 0x0000003b9592ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#58 0x0000003b8f80b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#59 0x0000003b8f81b2ed in ?? () from /lib64/libgobject-2.0.so.0
#60 0x0000003b8f81c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#61 0x0000003b8f81c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#62 0x0000003b95a2d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#63 0x0000003b95a3b7fb in gtk_window_propagate_key_event () from /usr/lib64/libgtk-x11-2.0.so.0
#64 0x0000003b95a3e57b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#65 0x0000003b9592ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#66 0x0000003b8f80b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#67 0x0000003b8f81b8e6 in ?? () from /lib64/libgobject-2.0.so.0
#68 0x0000003b8f81c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#69 0x0000003b8f81c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#70 0x0000003b95a2d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#71 0x0000003b95929785 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#72 0x0000003b9592a6d1 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#73 0x0000003b9304689c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#74 0x0000003b9242cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#75 0x0000003b9242fc0d in ?? () from /lib64/libglib-2.0.so.0
#76 0x0000003b9242ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#77 0x0000003b9592aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#78 0x0000003b909e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#79 0x0000003b90a72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#80 0x000000000043d09b in CodeBlocksApp::OnRun (this=0x1ad2b450) at app.cpp:788
#81 0x0000003b95499cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#82 0x000000000043b342 in main (argc=1, argv=0x80) at app.cpp:260

Latest debugger branch, on a simple project...
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 08, 2011, 03:19:13 pm
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
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 08, 2011, 03:27:28 pm
looking at the call-stack, I think that it does not happened on the batch parse stage.
because there is a function call:
Quote
CodeCompletion::OnValueTooltip
So, this crash happens when user hover on the editor.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 08, 2011, 03:40:38 pm
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.
Title: Re: Is CC crash, or Debugger plugin?
Post by: 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).
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on July 09, 2011, 10:56:08 am
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.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 09, 2011, 11:13:06 am
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.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on July 09, 2011, 11:49:28 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).
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.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 09, 2011, 12:50:39 pm
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...
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 10, 2011, 10:56:41 am
Does the parser test project work on linux?
For me it crashes badly on strange places :(
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 14, 2011, 04:11:46 am
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.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 14, 2011, 04:33:52 am
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

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.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 14, 2011, 04:52:21 am
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
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.
Title: Re: Is CC crash, or Debugger plugin?
Post by: 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;

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.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 14, 2011, 05:14:34 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).
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?
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on July 14, 2011, 06:57:37 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;

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!!
 :D
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 14, 2011, 01:56:39 pm
Loaden: Why are you using global critical section? Why don't you make it a member of the tokens tree (and then add Lock/Unlock methods or getCriticalSection() one)?

I'll test if this fixes my problems, because I had to disable CC, because it was unbearable...

p.s. can't test it before it is merged in the branch...
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 14, 2011, 02:31:49 pm
Loaden: Why are you using global critical section? Why don't you make it a member of the tokens tree (and then add Lock/Unlock methods or getCriticalSection() one)?
I agree with you. the critical section should be the member of Tokenstree or maybe Parser class. using a global variable is a bad idea.

But as loaden said, the wxString use reference counting, and not sure it is stable on the multi-thread usage. :D

EDIT
I mean this issue http://forums.wxwidgets.org/viewtopic.php?f=23&t=29705

especially this post:
http://forums.wxwidgets.org/viewtopic.php?f=23&p=127941#p127380
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 22, 2011, 01:27:03 pm
The tooltip crash seems to be gone, but I've got a deadlock probably...
Here is the backtrace
Code
#0  0x000000373d60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000373d608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x000000373d608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<value optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002afe0c53b2f7 in wxCriticalSection::Enter (this=0x2aaab3e98a80) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002afe0c53b321 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fff5b905210, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab3baca52 in ClassBrowserBuilderThread::ExpandItem (this=0x1f2e7000, item=...) at classbrowserbuilderthread.cpp:1009
#7  0x00002aaab3ba4206 in ClassBrowser::OnTreeItemExpanding (this=0x1f2ce770, event=...) at classbrowser.cpp:798
#8  0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#9  0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#10 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#11 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#12 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#13 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#14 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#15 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#16 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#17 0x0000003b39b3f2a1 in wxGenericTreeCtrl::Expand (this=<value optimized out>, itemId=<value optimized out>) at ./src/generic/treectlg.cpp:1792
#18 0x00002aaab3ba5a7f in ClassBrowser::OnSearch (this=0x1f2ce770, event=...) at classbrowser.cpp:746
#19 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#20 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#21 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#22 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#23 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#24 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#25 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#26 0x0000003b39a3839a in wxComboBox::OnChar (this=<value optimized out>, event=<value optimized out>) at ./src/gtk/combobox.cpp:1193
#27 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#28 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#29 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#30 0x0000003b399f8e7e in gtk_window_key_press_callback (widget=<value optimized out>, gdk_event=<value optimized out>, win=<value optimized out>) at ./src/gtk/window.cpp:1156
#31 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#32 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#33 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0
#34 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#35 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#36 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#37 0x0000003b3883b7fb in gtk_window_propagate_key_event () from /usr/lib64/libgtk-x11-2.0.so.0
#38 0x0000003b3883e57b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#39 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#40 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#41 0x000000373f61b8e6 in ?? () from /lib64/libgobject-2.0.so.0
#42 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#43 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#44 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#45 0x0000003b38729785 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#46 0x0000003b3872a6d1 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#47 0x0000003b3824689c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#48 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#49 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#50 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#51 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#52 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#53 0x0000003b39a72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#54 0x0000000000448d0a in CodeBlocksApp::OnRun (this=0x1debc050) at app.cpp:788
#55 0x0000003744c99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#56 0x000000000044c7bc in main (argc=1, argv=0x7fff5b906d08) at app.cpp:260

What I've done is:
1. Searched for a function in the symbol browser
2. The multi choice dlg showed
3. I've double clicked on a result
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on July 22, 2011, 05:12:51 pm
The crashes still exist?
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 22, 2011, 05:20:58 pm
The crashes still exist?
The original crash is 99% fixed. C::B has not crashed for the last couple of days.

The backtrace I've posted in the previous post is a different problem.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Jenna on July 22, 2011, 09:20:19 pm
The tooltip crash seems to be gone, but I've got a deadlock probably...
[...]

What I've done is:
1. Searched for a function in the symbol browser
2. The multi choice dlg showed
3. I've double clicked on a result

I get the same deadlock, but it happens immediately after I type the searcgstring and hit enter.

I think it happens, because ClassBrowser::OnSearch uses s_TokensTreeCritical and calls m_Tree->Expand(start); in line 746, which leads to a call of ClassBrowser::OnTreeItemExpanding and than ClassBrowserBuilderThread::ExpandItem.
ClassBrowserBuilderThread::ExpandItem also uses s_TokensTreeCritical to create a locker and here it hangs (of course), because we are still in the lock created in ClassBrowserBuilderThread::ExpandItem.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 22, 2011, 11:44:32 pm
Another problem with the tree is that it is flickering very badly during code editing, on my Centos.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 23, 2011, 01:43:33 pm
Another problem with the tree is that it is flickering very badly during code editing, on my Centos.
did you enable the real time parsing (which means parsing while editing), see the code below:
Code
void NativeParser::OnParserEnd(wxCommandEvent& event)
{
    if (!Manager::IsAppShuttingDown())
        Manager::Get()->GetLogManager()->DebugLog(_("NativeParser received parser end event."));

    Parser* parser = static_cast<Parser*>(event.GetEventObject());
    cbProject* project = static_cast<cbProject*>(event.GetClientData());
    const ParsingType type = static_cast<ParsingType>(event.GetInt());

    switch (type)
    {
    case ptCreateParser:
        {
            wxString log(F(_("Project '%s' parsing stage done!"), project
                         ? project->GetTitle().wx_str() : _T("*NONE*")));
            Manager::Get()->GetLogManager()->Log(log);
            Manager::Get()->GetLogManager()->DebugLog(log);
            CC_PROFILE_TIMER_LOG();
        }
        break;

    case ptAddFileToParser:
        Manager::Get()->GetLogManager()->DebugLog(F(_T("Add files to parser for project '%s'"), project
                                                  ? project->GetTitle().wx_str() : _T("*NONE*")));
        break;

    case ptReparseFile:
        Manager::Get()->GetLogManager()->DebugLog(F(_T("Reparsing modified files for project '%s'"), project
                                                  ? project->GetTitle().wx_str() : _T("*NONE*")));
        if (parser != m_Parser)
        {
            std::pair<cbProject*, Parser*> info = GetParserInfoByCurrentEditor();
            if (info.second && info.second != m_Parser)
            {
                Manager::Get()->GetLogManager()->DebugLog(_T("Start switch from OnParserEnd::ptReparseFile"));
                SwitchParser(info.first, info.second);
            }
        }
        break;

    case ptUndefined:
        Manager::Get()->GetLogManager()->DebugLog(F(_T("Parser event handling error of project '%s'"), project
                                                  ? project->GetTitle().wx_str() : _T("*NONE*")));
        return;
    }

    if (!event.GetString().IsEmpty())
        Manager::Get()->GetLogManager()->DebugLog(event.GetString());

    UpdateClassBrowser();
    m_TimerParsingOneByOne.Start(500, wxTIMER_ONE_SHOT);

    event.Skip();
}

look, the UpdateClassBrowser() will always be called after one parse finishes.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 23, 2011, 08:02:33 pm
Of course I have it enabled :)
Probably Freeze and Thaw should be used?
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on July 25, 2011, 04:40:48 am
Of course I have it enabled :)
Probably Freeze and Thaw should be used?
I just read some source code, and find that it use Freeze and Thaw, see:
Code
void ClassBrowserBuilderThread::BuildTree(bool useLock)

You can disable realtime parsing to see whether it happened again.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 25, 2011, 12:57:06 pm
The crashes still exist?
The original crash is 99% fixed. C::B has not crashed for the last couple of days.
Unfortunately it crashed again :(
Same backtrace... and again it has happened, when I was hovering with the mouse over a variable :(
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 26, 2011, 01:30:43 pm
And another lockup (dead lock probably!):

Code
(gdb) bt
#0  0x000000373d60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000373d608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x000000373d608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<value optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002b847045a2f7 in wxCriticalSection::Enter (this=0x2aaab3e98a80) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002b847045a321 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fffa337bb30, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab3c04248 in Parser::Reparse (this=0xde2c9e0, filename=..., isLocal=true) at parser/parser.cpp:692
#7  0x00002aaab3beb227 in NativeParser::ReparseFile (this=0xa1fbd50, project=0xbe0e160, filename=...) at nativeparser.cpp:1229
#8  0x00002aaab3bb5dd9 in CodeCompletion::OnRealtimeParsing (this=0xa1fbcd0, event=...) at codecompletion.cpp:3267
#9  0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#10 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#11 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#12 0x0000003b39af2106 in wxTimerBase::Notify (this=<value optimized out>) at ./src/common/timercmn.cpp:57
#13 0x0000003b399ed2e3 in timeout_callback (data=<value optimized out>) at ./src/gtk/timer.cpp:45
#14 0x000000373ee2d2bb in ?? () from /lib64/libglib-2.0.so.0
#15 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#16 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#17 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#18 0x0000003b386b88ca in gtk_dialog_run () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x0000003b39a5a7ba in wxMessageDialog::ShowModal (this=<value optimized out>) at ./src/gtk/msgdlg.cpp:117
#20 0x00002b84704b4611 in cbMessageBox (message=..., caption=..., style=256, parent=0x9901230, x=-1, y=-1) at globals.cpp:1219
#21 0x00002aaab3bb78c1 in CodeCompletion::OnGotoDeclaration (this=0xa1fbcd0, event=...) at codecompletion.cpp:2821
#22 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#23 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#24 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#25 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#26 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#27 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#28 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#29 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#30 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#31 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#32 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#33 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#34 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#35 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#36 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#37 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#38 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#39 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#40 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#41 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#42 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#43 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#44 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#45 0x0000003b39a55ed5 in gtk_menu_clicked_callback (widget=<value optimized out>, menu=<value optimized out>) at ./src/gtk/menu.cpp:653
#46 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#47 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0
#48 0x000000373f61c748 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#49 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#50 0x0000003b38831e1b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#51 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#52 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0
#53 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#54 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#55 0x0000003b3865f3ee in gtk_accel_group_activate () from /usr/lib64/libgtk-x11-2.0.so.0
#56 0x0000003b3865f4ef in gtk_accel_groups_activate () from /usr/lib64/libgtk-x11-2.0.so.0
#57 0x0000003b3883e559 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#58 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#59 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#60 0x000000373f61b8e6 in ?? () from /lib64/libgobject-2.0.so.0
#61 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#62 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#63 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#64 0x0000003b38729785 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#65 0x0000003b3872a6d1 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#66 0x0000003b3824689c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#67 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#68 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#69 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#70 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#71 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#72 0x0000003b39a72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#73 0x0000000000448d0a in CodeBlocksApp::OnRun (this=0x9520050) at app.cpp:788
#74 0x0000003744c99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#75 0x000000000044c7bc in main (argc=1, argv=0x7fffa337e0b8) at app.cpp:260
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on July 26, 2011, 02:37:59 pm
And another lockup (dead lock probably!):
Code
#8  0x00002aaab3bb5dd9 in CodeCompletion::OnRealtimeParsing (this=0xa1fbcd0, event=...) at codecompletion.cpp:3267
Unfortunately it seems the real-time parser causes more problems than benefits. I've disabled this for a while now and in fact all my crashes are gone (well also, due to the latest fixes in CC).
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on July 26, 2011, 02:40:11 pm
Code
#8  0x00002aaab3bb5dd9 in CodeCompletion::OnRealtimeParsing (this=0xa1fbcd0, event=...) at codecompletion.cpp:3267
[...]
#20 0x00002b84704b4611 in cbMessageBox (message=..., caption=..., style=256, parent=0x9901230, x=-1, y=-1) at globals.cpp:1219

#21 0x00002aaab3bb78c1 in CodeCompletion::OnGotoDeclaration (this=0xa1fbcd0, event=...) at codecompletion.cpp:2821
Interesting to note that you had queried to goto a declaration with a resulting message box (true?!) while Re-parsing kicked in - but there should actually be no changes when swapping header/source, or what did you do?
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 26, 2011, 02:56:20 pm
Yes, C::B locks and a message box is shown.
I'm not sure what I did exactly, probably I've hit the shortcut for goto declaration. I was over an incomplete include directive.

I was editing the source code. Almost all crashes/lockups happen after I've edit the source code.
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on July 26, 2011, 02:59:31 pm
I was editing the source code. Almost all crashes/lockups happen after I've edit the source code.
Just for convenience: Can you try if theses crashes still happen if you disable the real-time parsing? I would guess it'll be way more stable then.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 26, 2011, 03:03:50 pm
Yes, I've disabled 'Update parse when typing', I hope this is what you mean by real time parser.
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on July 26, 2011, 03:50:05 pm
Yes, I've disabled 'Update parse when typing', I hope this is what you mean by real time parser.
Yes, that's what I meant. So the kick-in is not caused by that. :-(
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 26, 2011, 04:00:50 pm
....So the kick-in is not caused by that. :-(
My mistake, I should have said - "I've just disabled it, lets see if the crashes are happening still!"
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on July 26, 2011, 04:21:07 pm
The "calltip crash" (the one in the std::set), just happened, so it is not related to the realtime parser.

This time it happened during debugging :( (99% of the time it was during debugging, but I guess this is just caused by the usage pattern).

Maybe it is time to start running it under valgrind.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 01, 2011, 07:51:23 pm
The "calltip crash" (the one in the std::set), just happened, so it is not related to the realtime parser.

This time it happened during debugging :( (99% of the time it was during debugging, but I guess this is just caused by the usage pattern).

Maybe it is time to start running it under valgrind.
I don't know how to use valgrind.
Maybe it is time to disable the option: "Compiler and debugger settings > Debugger settings > Evaluate expression under cursor"  ?
 :lol:
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 01, 2011, 08:23:13 pm
Or you should fix the bug  8)

Do you have anymore CC fixes in the pipeline or it is safe to do a merge?

p.s. you should try it (valgrind) it is pretty powerful and not that hard (on smaller projects, C::B is a bit biggish)
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 02, 2011, 10:52:52 am
Maybe it is time to start running it under valgrind.
I can't run Valgrind plugin in CB, here is the error log:
Quote
valgrind --version
valgrind-3.6.1
valgrind --leak-check=yes --xml=yes --xml-file=ValgrindOut.xml "devel/codeblocks" --debug-log --multiple-instance -ns -ni
devel/codeblocks: error while loading shared libraries: libcodeblocks.so: cannot open shared object file: No such file or directory

Then I run valgrind in bash:
Code
#!/bin/sh
APP_DIR=`dirname "$0"`
APP_DIR=`( cd "$APP_DIR" && pwd )`
export LD_LIBRARY_PATH=$APP_DIR:$LD_LIBRARY_PATH
valgrind --leak-check=yes --xml=yes --xml-file=ValgrindOut.xml $APP_DIR/parsertest $@
And I can't find any issue.


[attachment deleted by admin]
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 02, 2011, 11:17:20 am
It is better to run in from the command line.
Something like valgrind --leak-check=full ./app
Also try running it on the parsetest project.
Also look at the threaded engines of valgrind:
http://valgrind.org/docs/manual/hg-manual.html
http://valgrind.org/docs/manual/drd-manual.html
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 02, 2011, 04:31:15 pm
Valgrind can not give me any useful advise.
You can try REV7309, and disable the new option "Enable headers code-completion".
Maybe the issue is related with it.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 02, 2011, 04:38:30 pm
Do you see any "uninitialized write" kind of messages?

OK, when I get home all, merge the code in the branch and will do some testing.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 02, 2011, 05:08:08 pm
Do you see any "uninitialized write" kind of messages?
No.

Quote
valgrind --version
valgrind-3.6.1
valgrind --leak-check=full --xml=yes --xml-file=ValgrindOut.xml "devel/codeblocks" --debug-log --multiple-instance -ns -ni

** (codeblocks:13539): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:13539): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:13539): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:13539): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 02, 2011, 05:29:12 pm
Loaden: Why are you using --xml=yes and --xml-file? They are ment for application parsing, not human parsing.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 02, 2011, 05:31:27 pm
Loaden: Why are you using --xml=yes and --xml-file? They are ment for application parsing, not human parsing.
I am using CB's Valgrind plugin.
It's works now.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 02, 2011, 05:51:15 pm
Try from the command line, there is more output there.

And you're trying it on a big project for long time? If you just start C::B move around for a minute and quit, you'll find nothing.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 02, 2011, 06:43:28 pm
Try from the command line, there is more output there.

And you're trying it on a big project for long time? If you just start C::B move around for a minute and quit, you'll find nothing.
Here is the full log.
There has some leak report:
Quote
==18616== 176 bytes in 11 blocks are definitely lost in loss record 8,834 of 10,856
==18616==    at 0x4C279FC: calloc (vg_replace_malloc.c:467)
==18616==    by 0xA5C5AB9: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.2800.6)
==18616==    by 0x151A6967: ??? (in /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so)
==18616==    by 0x151A75EA: ??? (in /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so)
==18616==    by 0x84BEBCB: gtk_menu_shell_insert (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==18616==    by 0x5FDDFD4: wxChoice::GtkAddHelper(_GtkWidget*, unsigned int, wxString const&) (in /usr/lib/libwx_gtk2u_core-2.8.so.0.7.0)
==18616==    by 0x1C85BBCD: wxItemContainer::Append(wxString const&) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C8803F3: CodeCompletion::ParseFunctionsAndFillToolbar(bool) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C884F0F: CodeCompletion::OnParserEnd(wxCommandEvent&) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x68C4AD4: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
==18616==    by 0x68C4C5B: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
==18616==    by 0x68C4F93: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
But I don't got the reason.

Quote
==18616==
==18616== 320 bytes in 1 blocks are possibly lost in loss record 9,185 of 10,856
==18616==    at 0x4C279FC: calloc (vg_replace_malloc.c:467)
==18616==    by 0x4011868: _dl_allocate_tls (dl-tls.c:300)
==18616==    by 0x7DC8871: pthread_create@@GLIBC_2.2.5 (allocatestack.c:570)
==18616==    by 0x68C2F10: wxThread::Create(unsigned int) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
==18616==    by 0x6D63120: cbThreadPool::_SetConcurrentThreads(int) (in /home/loaden/DengYC/CodeBlocks/src/output/libcodeblocks.so)
==18616==    by 0x6D62F3C: cbThreadPool::SetConcurrentThreads(int) (in /home/loaden/DengYC/CodeBlocks/src/output/libcodeblocks.so)
==18616==    by 0x1C8CA584: cbThreadPool::cbThreadPool(wxEvtHandler*, int, int, unsigned int) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C8C4FE2: Parser::Parser(wxEvtHandler*, cbProject*) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C89FC19: NativeParser::NativeParser() (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C874508: CodeCompletion::CodeCompletion() (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C88B05A: PluginRegistrant<CodeCompletion>::CreatePlugin() (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x6E04BFE: PluginManager::LoadPlugin(wxString const&) (in /home/loaden/DengYC/CodeBlocks/src/output/libcodeblocks.so)

Quote
==18616== 320 bytes in 1 blocks are possibly lost in loss record 9,187 of 10,856
==18616==    at 0x4C279FC: calloc (vg_replace_malloc.c:467)
==18616==    by 0x4011868: _dl_allocate_tls (dl-tls.c:300)
==18616==    by 0x7DC8871: pthread_create@@GLIBC_2.2.5 (allocatestack.c:570)
==18616==    by 0x68C2F10: wxThread::Create(unsigned int) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
==18616==    by 0x6D63120: cbThreadPool::_SetConcurrentThreads(int) (in /home/loaden/DengYC/CodeBlocks/src/output/libcodeblocks.so)
==18616==    by 0x6D62F3C: cbThreadPool::SetConcurrentThreads(int) (in /home/loaden/DengYC/CodeBlocks/src/output/libcodeblocks.so)
==18616==    by 0x1C8CA584: cbThreadPool::cbThreadPool(wxEvtHandler*, int, int, unsigned int) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C8C4FE2: Parser::Parser(wxEvtHandler*, cbProject*) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C8A6B74: NativeParser::CreateParser(cbProject*) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x1C8B21B6: NativeParser::OnParsingOneByOneTimer(wxTimerEvent&) (in /home/loaden/DengYC/CodeBlocks/src/output/share/codeblocks/plugins/libcodecompletion.so)
==18616==    by 0x68C4AD4: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
==18616==    by 0x68C4C5B: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)

[attachment deleted by admin]
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 02, 2011, 07:33:36 pm
Loaden: memory leak detection in wx apps is impossible. Look only for invalid read and writes.

Edit: I cannot extract the last two files.
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on August 02, 2011, 08:52:59 pm
Edit: I cannot extract the last two files.
You'll need a quite recent (beta) version of 7-Zip.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 02, 2011, 09:21:15 pm
Code
7-Zip (A) [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Isn't this new enough? If it isn't 7zip is useless...
Title: Re: Is CC crash, or Debugger plugin?
Post by: ouch on August 02, 2011, 09:25:47 pm
You need the beta version, not the release version of 7-zip.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Jenna on August 02, 2011, 09:33:57 pm
7z can create volumes, with a maximum size, useful if there is a size-limit like for the attachements on the forum.

I don't know the correct way to unpack on linux, maybe there is some commandline for it, but I did not fiind.
What works: cp test.log.7z.001.7z test.log.7z and cat test.log.7z.002.7z >> test.log.7z and the unpack test.log.7z as usual.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 02, 2011, 10:14:22 pm
Hm, as far as I know we advise people to upload their files elsewhere, because we are space limited. So Loaden, please don't use this useless 7zip archiver, but use a paste bin service :)
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 03, 2011, 03:28:15 am
7z can create volumes, with a maximum size, useful if there is a size-limit like for the attachements on the forum.

I don't know the correct way to unpack on linux, maybe there is some commandline for it, but I did not fiind.
What works: cp test.log.7z.001.7z test.log.7z and cat test.log.7z.002.7z >> test.log.7z and the unpack test.log.7z as usual.
Sorry, I should say how to unpack it.
On Linux: RENAME test.log.7z.001.7z TO test.log.7z.001 , and RENAME test.log.7z.002.7z TO test.log.7z.002, Put them in the same folder, Then unpack test.log.7z.001

I can't upload "001" or "002" file types, so...
By the way, can we add "xz" file types for attachments?
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on August 03, 2011, 06:55:22 am
By the way, can we add "xz" file types for attachments?
Yes, but what is a "xz" file?
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 03, 2011, 07:04:15 am
By the way, can we add "xz" file types for attachments?
Yes, but what is a "xz" file?
http://en.wikipedia.org/wiki/Xz (http://en.wikipedia.org/wiki/Xz)
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on August 03, 2011, 07:09:11 am
http://en.wikipedia.org/wiki/Xz (http://en.wikipedia.org/wiki/Xz)
Another one? I already got used to tar.bz, bz2, zip, 7z, rar, ace... what else will follow? And as HDD disk space it cheap these days, why saving a few more bytes? I think we should stick with the formats that are supported by one extraction tool, namely 7z , (Win)ZIP or (Win)RAR. This will avoid forum messages like "What filetype is xz" and "I cannot open file "xz" in Code::Blocks (no, it's an archive :shock:) and "what tool do I need to extract "xz"? and alike. ;-) :lol:
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 03, 2011, 07:15:57 am
http://en.wikipedia.org/wiki/Xz (http://en.wikipedia.org/wiki/Xz)
Another one? I already got used to tar.bz, bz2, zip, 7z, rar, ace... what else will follow? And as HDD disk space it cheap these days, why saving a few more bytes? I think we should stick with the formats that are supported by one extraction tool, namely 7z , (Win)ZIP or (Win)RAR. This will avoid forum messages like "What filetype is xz" and "I cannot open file "xz" in Code::Blocks (no, it's an archive :shock:) and "what tool do I need to extract "xz"? and alike. ;-) :lol:
Because the forum attachment size is limited to 128KB, and XZ has a higher compression ratio.
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on August 03, 2011, 07:21:07 am
Because the forum attachment size is limited to 128KB, and XZ has a higher compression ratio.
Harhar... than it's easy: Use an external file sharing service for files > 128KB. ;-)
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 17, 2011, 04:39:53 pm
Another deadlock:

Code
(gdb) bt
#0  0x000000373d60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000373d608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x000000373d608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<value optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002b97f97bf88b in wxCriticalSection::Enter (this=0x2aaab3e99a80) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002b97f97bf8b5 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fffd1edfff0, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab3c030d7 in Parser::IsFileParsed (this=0xddc5040, filename=...) at parser/parser.cpp:1270
#7  0x00002aaab3bf25d0 in NativeParser::GetProjectByFilename (this=0xcd5e620, filename=...) at nativeparser.cpp:286
#8  0x00002aaab3bb9ace in CodeCompletion::OnReparsingTimer (this=0xcd5e5a0, event=...) at codecompletion.cpp:1898
#9  0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#10 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#11 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#12 0x0000003b39af2106 in wxTimerBase::Notify (this=<value optimized out>) at ./src/common/timercmn.cpp:57
#13 0x0000003b399ed2e3 in timeout_callback (data=<value optimized out>) at ./src/gtk/timer.cpp:45
#14 0x000000373ee2d2bb in ?? () from /lib64/libglib-2.0.so.0
#15 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#16 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#17 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#18 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#20 0x0000003b39a3b5d1 in wxDialog::ShowModal (this=<value optimized out>) at ./src/gtk/dialog.cpp:146
#21 0x0000003b39b017ed in wxGetSingleChoiceIndex (message=<value optimized out>, caption=<value optimized out>, n=<value optimized out>, choices=<value optimized out>, parent=<value optimized out>) at ./src/generic/choicdgg.cpp:127
#22 0x0000003b39b01915 in wxGetSingleChoiceIndex (message=<value optimized out>, caption=<value optimized out>, aChoices=<value optimized out>, parent=<value optimized out>, x=<value optimized out>, y=<value optimized out>, centre=<value optimized out>, width=Could not find the frame base for "wxGetSingleChoiceIndex(wxString const&, wxString const&, wxArrayString const&, wxWindow*, int, int, bool, int, int)".
)
    at ./src/generic/choicdgg.cpp:146
#23 0x00002aaab3bb6755 in CodeCompletion::OnGotoDeclaration (this=0xcd5e5a0, event=...) at codecompletion.cpp:2863
#24 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#25 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#26 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#27 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#28 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#29 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#30 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#31 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#32 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#33 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#34 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#35 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#36 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#37 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#38 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#39 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#40 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#41 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#42 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#43 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#44 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#45 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#46 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#47 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#48 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#49 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#50 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#51 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#52 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#53 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#54 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#55 0x00002aaab6f70ced in wxMenuCmd::Exec (this=0xdd1ee60, origin=0xdd5bc70, client=0xdd5bc70) at menuutils.cpp:543
#56 0x00002aaab6f63b11 in wxKeyBinder::OnChar (this=0xdcfd320, event=..., next=0xdd5bc70) at keybinder.cpp:1429
#57 0x00002aaab6f63c3b in wxBinderEvtHandler::OnChar (this=0xdd5c730, p=...) at keybinder.cpp:791
#58 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#59 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#60 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#61 0x0000003b399f8ef6 in gtk_window_key_press_callback (widget=<value optimized out>, gdk_event=<value optimized out>, win=<value optimized out>) at ./src/gtk/window.cpp:1034
#62 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#63 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#64 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0

BTW the std::set crash is not fixed, but now it is very rare. Debuggers branch latest revision on Centos Amd64 linux.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 23, 2011, 11:26:35 am
Pressing ctrl+shift+. is very deadlocky operation, it happened twice already today. Latest version of debugger's branch.
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 23, 2011, 03:33:06 pm
Pressing ctrl+shift+. is very deadlocky operation, it happened twice already today. Latest version of debugger's branch.
Try to disable the Symbols Browser.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 23, 2011, 03:50:31 pm
OK, but I'm not using the symbol browser at all.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 23, 2011, 04:11:55 pm
Disabled the symbols browser and got a crash instead of deadlock. Somewhere in AddToken().

Edit: And a deadlock switching to one just opened file...
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 24, 2011, 01:53:44 pm
Here is the backtrace from the newly-opened-file-deadlock:

Code
> bt 30
#0  0x000000373d60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000373d608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x000000373d608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002aaaab27d0a9 in wxCriticalSection::Enter (this=0x2aaab25e3868) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002aaaab27d0d3 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fffffffd8e0, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab23483e1 in Parser::IsFileParsed (this=0x1aecb30, filename=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1395
#7  0x00002aaab23316ee in NativeParser::GetProjectByFilename (this=0x11c7840, filename=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/nativeparser.cpp:276
#8  0x00002aaab23318aa in NativeParser::GetProjectByEditor (this=0x11c7840, editor=0x245f620) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/nativeparser.cpp:313
#9  0x00002aaab233195c in NativeParser::GetParserInfoByCurrentEditor (this=0x11c7840) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/nativeparser.cpp:3641
#10 0x00002aaab2332a09 in NativeParser::OnParserStart (this=0x11c7840, event=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/nativeparser.cpp:3381
#11 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<optimized out>, handler=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1239
#12 0x0000003744cfce12 in wxEvtHandler::SearchDynamicEventTable (this=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1421
#13 0x0000003744cfcec2 in wxEvtHandler::ProcessEvent (this=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1297
#14 0x00002aaab2347c6e in Parser::ProcessParserEvent (this=0x1aecb30, type=ptCreateParser, id=928, info=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1412
#15 0x00002aaab234ad38 in Parser::OnBatchTimer (this=0x1aecb30, event=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1312
#16 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<optimized out>, handler=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1239
#17 0x0000003744cfce12 in wxEvtHandler::SearchDynamicEventTable (this=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1421
#18 0x0000003744cfcec2 in wxEvtHandler::ProcessEvent (this=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1297
#19 0x0000003b39af2106 in wxTimerBase::Notify (this=<optimized out>) at ./src/common/timercmn.cpp:57
#20 0x0000003b399ed2e3 in timeout_callback (data=<optimized out>) at ./src/gtk/timer.cpp:45
#21 0x000000373ee2d2bb in ?? () from /lib64/libglib-2.0.so.0
#22 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#23 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#24 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#25 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#26 0x0000003b399e456d in wxEventLoop::Run (this=<optimized out>) at ./src/gtk/evtloop.cpp:76
#27 0x0000003b39a72378 in wxAppBase::MainLoop (this=<optimized out>) at ./src/common/appcmn.cpp:312
#28 0x000000000043a20a in CodeBlocksApp::OnRun (this=0x759fb0) at /home/tpetrov/projects/codeblocks/trunk1/src/src/app.cpp:788
#29 0x0000003744c99cc1 in wxEntry (argc=<optimized out>, argv=<optimized out>) at ./src/common/init.cpp:448

The two interesting frames are:
Code
#6  0x00002aaab23483e1 in Parser::IsFileParsed (this=0x1aecb30, filename=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1395
#15 0x00002aaab234ad38 in Parser::OnBatchTimer (this=0x1aecb30, event=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1312

Good luck fixing it and please do more testing before committing a fix...
Especially on linux.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 24, 2011, 02:05:25 pm
BTW:
The CCLockerTrack class is useless, because when you get a dead lock, you cannot inspect the debug log.
Or do I miss something?
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on August 24, 2011, 02:36:46 pm
BTW:
The CCLockerTrack class is useless, because when you get a dead lock, you cannot inspect the debug log.
Or do I miss something?
You'll need to use the C::B command line option to log to a file in that case.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 24, 2011, 02:54:40 pm
OK, I've just replaced the logging with a simple printf, simple but effective :)
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 24, 2011, 03:02:02 pm
Here is the backtrace from the newly-opened-file-deadlock:

Code
> bt 30
#0  0x000000373d60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000373d608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x000000373d608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002aaaab27d0a9 in wxCriticalSection::Enter (this=0x2aaab25e3868) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002aaaab27d0d3 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fffffffd8e0, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab23483e1 in Parser::IsFileParsed (this=0x1aecb30, filename=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1395
#7  0x00002aaab23316ee in NativeParser::GetProjectByFilename (this=0x11c7840, filename=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/nativeparser.cpp:276
#8  0x00002aaab23318aa in NativeParser::GetProjectByEditor (this=0x11c7840, editor=0x245f620) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/nativeparser.cpp:313
#9  0x00002aaab233195c in NativeParser::GetParserInfoByCurrentEditor (this=0x11c7840) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/nativeparser.cpp:3641
#10 0x00002aaab2332a09 in NativeParser::OnParserStart (this=0x11c7840, event=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/nativeparser.cpp:3381
#11 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<optimized out>, handler=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1239
#12 0x0000003744cfce12 in wxEvtHandler::SearchDynamicEventTable (this=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1421
#13 0x0000003744cfcec2 in wxEvtHandler::ProcessEvent (this=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1297
#14 0x00002aaab2347c6e in Parser::ProcessParserEvent (this=0x1aecb30, type=ptCreateParser, id=928, info=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1412
#15 0x00002aaab234ad38 in Parser::OnBatchTimer (this=0x1aecb30, event=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1312
#16 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<optimized out>, handler=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1239
#17 0x0000003744cfce12 in wxEvtHandler::SearchDynamicEventTable (this=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1421
#18 0x0000003744cfcec2 in wxEvtHandler::ProcessEvent (this=<optimized out>, event=<optimized out>) at ./src/common/event.cpp:1297
#19 0x0000003b39af2106 in wxTimerBase::Notify (this=<optimized out>) at ./src/common/timercmn.cpp:57
#20 0x0000003b399ed2e3 in timeout_callback (data=<optimized out>) at ./src/gtk/timer.cpp:45
#21 0x000000373ee2d2bb in ?? () from /lib64/libglib-2.0.so.0
#22 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#23 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#24 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#25 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#26 0x0000003b399e456d in wxEventLoop::Run (this=<optimized out>) at ./src/gtk/evtloop.cpp:76
#27 0x0000003b39a72378 in wxAppBase::MainLoop (this=<optimized out>) at ./src/common/appcmn.cpp:312
#28 0x000000000043a20a in CodeBlocksApp::OnRun (this=0x759fb0) at /home/tpetrov/projects/codeblocks/trunk1/src/src/app.cpp:788
#29 0x0000003744c99cc1 in wxEntry (argc=<optimized out>, argv=<optimized out>) at ./src/common/init.cpp:448

The two interesting frames are:
Code
#6  0x00002aaab23483e1 in Parser::IsFileParsed (this=0x1aecb30, filename=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1395
#15 0x00002aaab234ad38 in Parser::OnBatchTimer (this=0x1aecb30, event=...) at /home/tpetrov/projects/codeblocks/trunk1/src/plugins/codecompletion/parser/parser.cpp:1312

Good luck fixing it and please do more testing before committing a fix...
Especially on linux.
Thanks a lot!
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 26, 2011, 08:27:45 am
The crashes still exist?
The original crash is 99% fixed. C::B has not crashed for the last couple of days.
Unfortunately it crashed again :(
Same backtrace... and again it has happened, when I was hovering with the mouse over a variable :(
Try rev7419?
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 26, 2011, 12:23:44 pm
After the next merge :)
The current debugger_branch revision is working relatively stable :)

killerbot: can you make a nightly build for trunk?
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 28, 2011, 11:30:31 am
After the next merge :)
The current debugger_branch revision is working relatively stable :)

killerbot: can you make a nightly build for trunk?
Remember: Disable symbols  browser! :D
Title: Re: Is CC crash, or Debugger plugin?
Post by: killerbot on August 28, 2011, 01:10:32 pm
what is the current state of CC on one hand with respect to stability ?

and what is the current state of the debugger branch with respect to stability ?
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 28, 2011, 02:46:32 pm
what is the current state of CC on one hand with respect to stability ?
The current HEAD works well on Windows 7 or Linux Mint 11.
It's ready for next nightly build. :)
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 28, 2011, 02:52:22 pm
The current HEAD works well on Windows 7 or Linux Mint 11.
You said that the last time, too  8)
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 28, 2011, 04:04:03 pm
The current HEAD works well on Windows 7 or Linux Mint 11.
You said that the last time, too  8)
If only test from me, then, yes, It has been stable enough.
So, how do? :?
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 28, 2011, 04:11:38 pm
Oh, waiting.
I forgot test one parser per whole workspace. :(

EDIT: Test done, works well for me.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on August 28, 2011, 04:26:17 pm
As far as I can tell, the most bugs are coming out when you test in production.
Run it for a week with complex projects and then call it stable :)
But what you do is commit, then do some tests (you can say what tests you do) and then call it stable 15 minutes after the commit. :)

You even don't have an automatic test suite for the parser!
How can you be sure that you've not broken the parser with a simple change somewhere in the code?
And the last commits are not simple changes :)
Title: Re: Is CC crash, or Debugger plugin?
Post by: Loaden on August 28, 2011, 04:45:07 pm
I am now work environment using Eclipse + CDT + CMake, not CB.
So I am afraid there is not enough time to test.
I present all of the commit, just to maintain existing code.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on August 29, 2011, 07:02:38 am
Here is my points:
1, we must use some automatic test mechanism, otherwise, it's hard to find bugs.
2, TokensTree are shared resource. and a Token*(or a TokenIdx) can be invalid.
For example:
step one: you create a browser tree
step two: you parserthread has add some more Tokens to the TokensTree, or maybe, it delete some Tokens.
step three: Your browsertree entry will become invalid, this is quite simple, because an browsertree entry use a Token*, if you change the TokensTree, the Token* may become invalid.

look at the declaration:
Code
class CBTreeData : public wxTreeItemData
{
public:
    CBTreeData(SpecialFolder sf = sfToken, Token* token = 0, short int kindMask = 0xffff, int parentIdx = -1) :
        m_Token(token),
        m_KindMask(kindMask),
        m_SpecialFolder(sf),
        m_TokenIndex(token ? token->m_Index : -1),
        m_TokenKind(token ? token->m_TokenKind : tkUndefined),
        m_TokenName(token ? token->m_Name : _T("")),
        m_ParentIndex(parentIdx),
        m_Ticket(token ? token->GetTicket() : 0)
    {
    }
    Token*        m_Token;
    short int     m_KindMask;
    SpecialFolder m_SpecialFolder;
    int           m_TokenIndex;
    TokenKind     m_TokenKind;
    wxString      m_TokenName;
    int           m_ParentIndex;
    unsigned long m_Ticket;
};

So, the solution should be:
1, a browser tree(and tree entry) is only valid when you build it after all parserthreads have finished their work.
2, if the TokensTree is modified by the parserthread, we need update/redraw browsertree.

So, I think if the parserthread is still working, it is not safe to build the browsertree. The only time to build the browsertree is all parserthread are done, and the TokensTree is at that time is frozen, the browsertree is safe to build. Every modification on the Tokenstree should trigger a re-flash on the browsertree.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 02, 2011, 12:49:35 pm
Just started testing the next changes in CC and it seems it is stable. 2-3 hours only.
But there is one problem in the latest versions (not sure when it stopped working): Completion for the includes doesn't work.

I'm typing "#include <st|" then pressing ctrl+space and nothing shows. (| is where my cursor is at the moment, when I pressed ctrl+space).
This feature used to work at some time and it was great:)

Latest debugger branch on Centos Linux 5.6 amd64 with gcc-4.1.2
Title: Re: Is CC crash, or Debugger plugin?
Post by: Jenna on September 02, 2011, 12:58:17 pm
Just started testing the next changes in CC and it seems it is stable. 2-3 hours only.
But there is one problem in the latest versions (not sure when it stopped working): Completion for the includes doesn't work.

I'm typing "#include <st|" then pressing ctrl+space and nothing shows. (| is where my cursor is at the moment, when I pressed ctrl+space).
This feature used to work at some time and it was great:)

Latest debugger branch on Centos Linux 5.6 amd64 with gcc-4.1.2
I stumbled over it also:
there is a new option: "Settings -> Editor... -> Code completion -> Code completion -> Enable headers code-completion", that is unchecked by default.

@all devs:
I would prefer, not to change former behaviour, if settings are made configurable.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 02, 2011, 01:04:07 pm
@all devs:
I would prefer, not to change former behaviour, if settings are made configurable.
me too :)
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 02, 2011, 01:07:21 pm
Loaden:
Can you make the header completion to be case insensitive?
(there is option controlling this for the normal completion, which should be taken into account)

My problem is that if I have mixed case header file and If I type only lower cases, the first wrong character closes the completion list :(
Title: Re: Is CC crash, or Debugger plugin?
Post by: MortenMacFly on September 02, 2011, 01:29:33 pm
Just started testing the next changes in CC and it seems it is stable. 2-3 hours only.
Me too, but I found a crash pretty fast (on Windows), luckily its already fixed in head.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 02, 2011, 01:44:16 pm
Steps to reproduce?
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 12, 2011, 04:26:17 pm
I have new deadlock here (debugger branch r7444) :
Code
(gdb) bt
#0  0x000000373d60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000373d608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x000000373d608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<value optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002ba4c8de5b1b in wxCriticalSection::Enter (this=0x2aaab3e9a980) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002ba4c8de5b45 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fffba483d50, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab3c03ee3 in Parser::IsFileParsed (this=0x4ee4400, filename=...) at parser/parser.cpp:1308
#7  0x00002aaab3bf321c in NativeParser::GetProjectByFilename (this=0x3ede040, filename=...) at nativeparser.cpp:269
#8  0x00002aaab3bb88b0 in CodeCompletion::OnReparsingTimer (this=0x3eddfc0, event=...) at codecompletion.cpp:1935
#9  0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#10 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#11 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#12 0x0000003b39af2106 in wxTimerBase::Notify (this=<value optimized out>) at ./src/common/timercmn.cpp:57
#13 0x0000003b399ed2e3 in timeout_callback (data=<value optimized out>) at ./src/gtk/timer.cpp:45
#14 0x000000373ee2d2bb in ?? () from /lib64/libglib-2.0.so.0
#15 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#16 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#17 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#18 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#20 0x0000003b39a3b5d1 in wxDialog::ShowModal (this=<value optimized out>) at ./src/gtk/dialog.cpp:146
#21 0x0000003b39b017ed in wxGetSingleChoiceIndex (message=<value optimized out>, caption=<value optimized out>, n=<value optimized out>, choices=<value optimized out>, parent=<value optimized out>) at ./src/generic/choicdgg.cpp:127
#22 0x0000003b39b01915 in wxGetSingleChoiceIndex (message=<value optimized out>, caption=<value optimized out>, aChoices=<value optimized out>, parent=<value optimized out>, x=<value optimized out>, y=<value optimized out>, centre=<value optimized out>, width=Could not find the frame base for "wxGetSingleChoiceIndex(wxString const&, wxString const&, wxArrayString const&, wxWindow*, int, int, bool, int, int)".
)
    at ./src/generic/choicdgg.cpp:146
#23 0x00002aaab3bc7d26 in CodeCompletion::OnGotoDeclaration (this=0x3eddfc0, event=...) at codecompletion.cpp:2932
#24 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#25 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#26 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#27 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#28 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#29 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#30 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#31 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#32 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#33 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#34 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#35 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#36 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#37 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#38 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#39 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#40 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#41 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#42 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#43 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#44 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#45 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#46 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#47 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#48 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#49 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#50 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#51 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#52 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#53 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#54 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#55 0x00002aaab6f71ced in wxMenuCmd::Exec (this=0x4e89950, origin=0x2aaaac219ac0, client=0x2aaaac219ac0) at menuutils.cpp:543
#56 0x00002aaab6f64b11 in wxKeyBinder::OnChar (this=0x4e71880, event=..., next=0x2aaaac219ac0) at keybinder.cpp:1429
#57 0x00002aaab6f64c3b in wxBinderEvtHandler::OnChar (this=0x2aaaac21bc70, p=...) at keybinder.cpp:791
#58 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#59 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#60 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#61 0x0000003b399f8ef6 in gtk_window_key_press_callback (widget=<value optimized out>, gdk_event=<value optimized out>, win=<value optimized out>) at ./src/gtk/window.cpp:1034
#62 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#63 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#64 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#65 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#66 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#67 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#68 0x0000003b3883b7fb in gtk_window_propagate_key_event () from /usr/lib64/libgtk-x11-2.0.so.0
#69 0x0000003b3883e57b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#70 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#71 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#72 0x000000373f61b8e6 in ?? () from /lib64/libgobject-2.0.so.0
#73 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#74 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#75 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#76 0x0000003b38729785 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#77 0x0000003b3872a6d1 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#78 0x0000003b3824689c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#79 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#80 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#81 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#82 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#83 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#84 0x0000003b39a72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#85 0x0000000000449d8a in CodeBlocksApp::OnRun (this=0x32d5090) at app.cpp:788
#86 0x0000003744c99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#87 0x000000000044d83c in main (argc=1, argv=0x7fffba4867f8) at app.cpp:260

Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 12, 2011, 09:30:00 pm
Loaden:
This is pretty major deadlock here!!!!
Because you are taking the lock in CodeCompletion::OnGotoDeclaration, for very long time (the lock is taken during the dialog.ShowModal()), and if you call a function which takes the lock, you get a deadlock, pretty scary stuff.

One solution is:
0. take the lock
1. generate the list of matches
2. release the lock
3. show the dialog

Keep in mind the the event loop is running when you call ShowModal() and other event handlers could be called.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 14, 2011, 01:43:42 am
Here is a patch that should fix the problem: http://smrt.is-a-geek.org/codeblocks/patches/goto_declr_deadlock.patch

Please test and report if there are problems, if there are no problems in the next couple of days, I'll commit it.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on September 14, 2011, 08:26:02 am
Here is a patch that should fix the problem: http://smrt.is-a-geek.org/codeblocks/patches/goto_declr_deadlock.patch

Please test and report if there are problems, if there are no problems in the next couple of days, I'll commit it.
I review the patch, but I don't think this patch release the lock before showing the selection dialog.
After the patch, it looks like:
Code

    {
        TRACK_THREAD_LOCKER(s_TokensTreeCritical);
        wxCriticalSectionLocker locker(s_TokensTreeCritical);
        THREAD_LOCKER_SUCCESS(s_TokensTreeCritical);

        TokensTree* tokens = m_NativeParser.GetParser().GetTokensTree();

        .......
        .......

        if (token)
        {
            if (   wxGetKeyState(WXK_CONTROL)
                && wxGetKeyState(WXK_SHIFT)
                && (  event.GetId() == idGotoDeclaration
                   || event.GetId() == idGotoImplementation ) )
            {
                // beware this  code can lead to a deadlock (because of double locking from single thread)
                CCDebugInfo info(nullptr, &m_NativeParser.GetParser(), token);
                info.ShowModal();
            }
            else if (isImpl)
            {
                targetEditor = edMan->Open(token->GetImplFilename());
                editorLine = token->m_ImplLine - 1;
            }
            else if (isDecl)
            {
                targetEditor = edMan->Open(token->GetFilename());
                editorLine = token->m_Line - 1;
            }

            tokenFound = true;
        }
    }

Still not safe to show the CCDebugInfo dialog.
Can you give some explanation?
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 14, 2011, 08:31:55 am
Unfortunately you're right :(

p.s. I don't care for CCDebugInfo, it is not something a user uses in his daily programming tasks.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 14, 2011, 09:49:59 am
BTW there is another problem in this function:

This fragment should be inside the lock, too:
Code
		// get the matching set
TokenIdxSet result;
m_NativeParser.MarkItemsByAI(result, true, false, true, endPos);

Example:
Code
array_of_pointers;
{
    lock;
    collect_some(array_of_pointers);
}

{
   lock
   use(array_of_pointer);
}
This code is broken because between the two locks another thread can acquire the lock and delete some of the objects pointed in the array.

Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on September 14, 2011, 09:55:24 am
I don't like such lockers, as it make the code too broken to read and maintain. So, I always avoid to discuss how to place lockers, as I think all of them should be removed. :D
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 14, 2011, 09:56:44 am
And how do you make threaded programs correct without lockers?
As far as I know there is no known way to achieve this in an imperative programming language.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on September 14, 2011, 10:00:26 am
And how do you make threaded programs correct without lockers?
I suggest do not generate "suggestion list" when parserthread is running. This can avoid a lot of lockers in CC's code.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 14, 2011, 10:33:18 am
How would you know if the thread is not running?
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 14, 2011, 11:04:17 am
Okay, next patch, should fix the bug for real: http://smrt.is-a-geek.org/codeblocks/patches/goto_declr_deadlock2.patch

CCDebugInfo dialog is highly crippled with this patch, so probably it is better to remove it completely.
Title: Re: Is CC crash, or Debugger plugin?
Post by: ollydbg on September 14, 2011, 11:10:24 am
How would you know if the thread is not running?
This also involve a shared resource, but we can check/lock the state when we enter the handler function.
Did you remember the old way CC generate call tip?
If the parserthread is running, it will show some tip like "parser is already running...".
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 28, 2011, 08:26:24 pm
No one has reported any problems and I found non in the time I was using it, so the patch is committed.
Title: Re: Is CC crash, or Debugger plugin?
Post by: oBFusCATed on September 29, 2011, 01:28:17 pm
I'm witnessing another very unpleasant crash/deadlock/race:
Code
(gdb) bt
#0  0x000000373cacb696 in poll () from /lib64/libc.so.6
#1  0x00000038cdbccba4 in wxapp_poll_func (ufds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ./src/gtk/app.cpp:266
#2  0x00000038ca02fa3d in ?? () from /lib64/libglib-2.0.so.0
#3  0x00000038ca02ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#4  0x00000038cc52aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#5  0x00000038cdbe456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#6  0x00000038cdc3b5d1 in wxDialog::ShowModal (this=<value optimized out>) at ./src/gtk/dialog.cpp:146
#7  0x0000003a0a41b2d9 in wxDebugReportPreviewStd::Show (this=<value optimized out>, dbgrpt=<value optimized out>) at ./src/generic/dbgrptg.cpp:522
#8  0x000000000043c850 in CodeBlocksApp::OnFatalException (this=<value optimized out>) at app.cpp:824
#9  0x0000003744d010ec in wxFatalSignalHandler () at ./src/unix/utilsunx.cpp:1109
#10 <signal handler called>
#11 0x000000373d608ca0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#12 0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<value optimized out>) at ./src/unix/threadpsx.cpp:248
#13 0x0000003744cfd265 in Enter (this=<value optimized out>, event=<value optimized out>) at ./include/wx/thread.h:271
#14 wxEvtHandler::AddPendingEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1142
#15 0x00002aaab84c5a11 in wxPostEvent (this=0x6026fb0, msg=...) at /usr/include/wx-2.8/wx/event.h:2570
#16 CCLogger::DebugLog (this=0x6026fb0, msg=...) at parser/token.h:159
#17 0x00002aaab84d881d in NativeParser::GetGCCCompilerDirs (this=<value optimized out>, cpp_compiler=...) at nativeparser.cpp:1095
#18 0x00002aaab84da012 in NativeParser::AddCompilerDirs (this=0x601b9d0, project=0x686d6b0, parser=0x70cb300) at nativeparser.cpp:797
#19 0x00002aaab84dfd1c in NativeParser::DoFullParsing (this=0x601b9d0, project=0x686d6b0, parser=0x70cb300) at nativeparser.cpp:1258
#20 0x00002aaab84ebfaf in NativeParser::CreateParser (this=0x601b9d0, project=0x686d6b0) at nativeparser.cpp:1123
#21 0x00002aaab84a7f51 in CodeCompletion::OnProjectActivated (this=0x601b950, event=...) at codecompletion.cpp:1862
#22 0x00002b47e8529a10 in Manager::ProcessEvent (this=<value optimized out>, event=...) at manager.cpp:174
#23 0x00002b47e856c415 in ProjectManager::SetProject (this=0x5263f00, project=0x686d6b0, refresh=true) at projectmanager.cpp:525
#24 0x00002b47e8571fbf in ProjectManager::EndLoadingWorkspace (this=0x5263f00) at projectmanager.cpp:3155
#25 0x00002b47e8572597 in ProjectManager::LoadWorkspace (this=0x5263f00, filename=...) at projectmanager.cpp:1199
#26 0x000000000048cf31 in MainFrame::OpenGeneric (this=0x51460d0, filename=..., addToHistory=true) at main.cpp:1660
#27 0x000000000049bc8c in MainFrame::OnStartHereLink (this=0x51460d0, event=<value optimized out>) at main.cpp:2024
#28 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#29 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#30 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#31 0x0000003744cfd3d0 in wxEvtHandler::ProcessPendingEvents (this=<value optimized out>) at ./src/common/event.cpp:1196
#32 0x0000003744c6214e in wxAppConsole::ProcessPendingEvents (this=<value optimized out>) at ./src/common/appbase.cpp:294
#33 0x00000038cdc723d6 in wxAppBase::ProcessIdle (this=<value optimized out>) at ./src/common/appcmn.cpp:435
#34 0x00000038cdbcd99f in wxapp_idle_callback () at ./src/gtk/app.cpp:213
#35 0x00000038ca02cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#36 0x00000038ca02fc0d in ?? () from /lib64/libglib-2.0.so.0
#37 0x00000038ca02ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#38 0x00000038cc52aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#39 0x00000038cdbe456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#40 0x00000038cdc72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#41 0x000000000043e49b in CodeBlocksApp::OnRun (this=0x5) at app.cpp:788
#42 0x0000003744c99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#43 0x000000000043c742 in main (argc=1, argv=0x7fff8a0e4200) at app.cpp:260
This happens right after I start new instance of C::B and open large workspace.
Has someone seen such crashes?
This is on Centos amd64, C::B debugger's branch r7474.