Author Topic: Is CC crash, or Debugger plugin?  (Read 75043 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #105 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.

(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5931
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Is CC crash, or Debugger plugin?
« Reply #106 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
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #107 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5931
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Is CC crash, or Debugger plugin?
« Reply #108 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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #109 on: September 14, 2011, 10:33:18 am »
How would you know if the thread is not running?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #110 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5931
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Is CC crash, or Debugger plugin?
« Reply #111 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...".
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #112 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #113 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]