Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: oBFusCATed on May 16, 2012, 10:27:45 am

Title: wxExecute problems on first start...
Post by: oBFusCATed on May 16, 2012, 10:27:45 am
I don't know what is the reason, but the first time I run codeblocks and open the latest codeblocks-unix.cbp, I get a dead lock/infinite loop.
See the backtrace below.
I see this for the second day running.
First time I saw two wx-config processes as zombie children of codeblocks and today there are two g++ zombies.
This problem happens only the first time I run codeblocks after I've started the computer.
Centos 5.x 64bit wxgtk 2.8.12...

Also the first time a try to debug something containing macros, starting the debugger fails, if I hit f8 again it works as expected :(

Has anyone seen such problems?

Code
(gdb) bt
#0  0x0000003701bc4dd2 in Update (this=<value optimized out>, execData=...) from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#1  wxGUIAppTraits::WaitForChild (this=<value optimized out>, execData=...) at src/unix/utilsunx.cpp:1305
#2  0x00000036fff0207d in wxExecute (argv=0x370015f3a0, flags=9, process=0x21aa2a90) at src/unix/utilsunx.cpp:673
#3  0x00000036fff02964 in wxExecute (command=<value optimized out>, flags=9, process=0x21aa2a90) at src/unix/utilsunx.cpp:344
#4  0x00000036ffeff7d0 in wxDoExecuteWithCapture (command=..., output=..., error=0x0, flags=9) at src/common/utilscmn.cpp:685
#5  0x00002aaab8845e76 in NativeParser::AddCompilerPredefinedMacros (this=<value optimized out>, project=0x2119eb20, parser=0x21aabce0) at nativeparser.cpp:897
#6  0x00002aaab8847745 in NativeParser::DoFullParsing (this=0x2075a530, project=0x2119eb20, parser=0x21aabce0) at nativeparser.cpp:1330
#7  0x00002aaab8849a07 in NativeParser::CreateParser (this=0x2075a530, project=0x2119eb20) at nativeparser.cpp:1184
#8  0x00002aaab8849f1b in NativeParser::OnEditorActivated (this=0x2075a530, editor=<value optimized out>) at nativeparser.cpp:2375
#9  0x00002aaab8816696 in CodeCompletion::OnEditorActivatedTimer (this=0x2075a4b0, event=<value optimized out>) at codecompletion.cpp:2363
#10 0x00000036ffefcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=0xd, event=...) at src/common/event.cpp:1239
#11 0x00000036ffefcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=..., self=0x2075a4b0) at src/common/event.cpp:906
#12 0x00000036ffefcee9 in wxEvtHandler::ProcessEvent (this=0x2075a4b0, event=...) at src/common/event.cpp:1301
#13 0x0000003701cf1bc6 in wxTimerBase::Notify (this=0x2075a9a0) at src/common/timercmn.cpp:57
#14 0x0000003701becda3 in timeout_callback (data=<value optimized out>) at src/gtk/timer.cpp:45
#15 0x00000038ca02d2bb in ?? () from /lib64/libglib-2.0.so.0
#16 0x00000038ca02cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#17 0x00000038ca02fc0d in ?? () from /lib64/libglib-2.0.so.0
#18 0x00000038ca03011e in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#19 0x00000038cc52a921 in gtk_main_iteration () from /usr/lib64/libgtk-x11-2.0.so.0
#20 0x0000003701bcd39d in wxApp::Yield (this=0x1f43a8e0, onlyIfNeeded=<value optimized out>) at src/gtk/app.cpp:109
#21 0x00000036ffeff290 in wxYield () at src/common/utilscmn.cpp:977
#22 0x0000003701bc4dfc in wxGUIAppTraits::WaitForChild (this=<value optimized out>, execData=...) at src/unix/utilsunx.cpp:1323
#23 0x00000036fff0207d in wxExecute (argv=0x370015f3a0, flags=9, process=0x21a4bb80) at src/unix/utilsunx.cpp:673
#24 0x00000036fff02964 in wxExecute (command=<value optimized out>, flags=9, process=0x21a4bb80) at src/unix/utilsunx.cpp:344
#25 0x00000036ffeff7d0 in wxDoExecuteWithCapture (command=..., output=..., error=0x7fffd9196d20, flags=9) at src/common/utilscmn.cpp:685
#26 0x00002aaab883f14b in NativeParser::GetGCCCompilerDirs (this=<value optimized out>, cpp_compiler=...) at nativeparser.cpp:1106
#27 0x00002aaab883fae2 in NativeParser::AddGCCCompilerDirs (this=0x2075a530, compiler=0x20d0d9a0, parser=0x21a49850) at nativeparser.cpp:1150
#28 0x00002aaab884500b in NativeParser::AddCompilerDirs (this=0x2075a530, project=0x2119eb20, parser=0x21a49850) at nativeparser.cpp:836
#29 0x00002aaab88476dc in NativeParser::DoFullParsing (this=0x2075a530, project=0x2119eb20, parser=0x21a49850) at nativeparser.cpp:1327
#30 0x00002aaab8849a07 in NativeParser::CreateParser (this=0x2075a530, project=0x2119eb20) at nativeparser.cpp:1184
#31 0x00002aaab8812194 in CodeCompletion::OnProjectActivated (this=0x2075a4b0, event=...) at codecompletion.cpp:1764
#32 0x0000003c98e72090 in Manager::ProcessEvent (this=<value optimized out>, event=...) at manager.cpp:169
#33 0x0000003c98eb1fb9 in ProjectManager::SetProject (this=0x1fb65f10, project=0x2119eb20, refresh=true) at projectmanager.cpp:669
#34 0x0000003c98eb23b6 in ProjectManager::LoadProject (this=0x1fb65f10, filename=..., activateIt=true) at projectmanager.cpp:972
#35 0x000000000049f811 in MainFrame::DoOpenProject (this=0x1f835450, filename=..., addToHistory=true) at main.cpp:1806
#36 0x000000000049fde8 in MainFrame::OpenGeneric (this=0x1f835450, filename=..., addToHistory=true) at main.cpp:1755
#37 0x00000000004a0c8c in MainFrame::OnDropFiles (this=0x1f835450, files=...) at main.cpp:2653
#38 0x00000000004a12a4 in MainFrame::DoOnFileOpen (this=0x1f835450, bProject=true) at main.cpp:2723
#39 0x00000000004a5ddd in MainFrame::OnStartHereLink (this=0x1f835450, event=...) at main.cpp:2098
#40 0x00000036ffefcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=0xd, event=...) at src/common/event.cpp:1239
#41 0x00000036ffefcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=..., self=0x1f835450) at src/common/event.cpp:906
#42 0x00000036ffefcee9 in wxEvtHandler::ProcessEvent (this=0x1f835450, event=...) at src/common/event.cpp:1301
#43 0x00000036ffefd3d0 in wxEvtHandler::ProcessPendingEvents (this=0x1f835450) at src/common/event.cpp:1196
#44 0x00000036ffe6214e in wxAppConsole::ProcessPendingEvents (this=<value optimized out>) at src/common/appbase.cpp:294
#45 0x0000003701c71e96 in wxAppBase::ProcessIdle (this=0x21a9fc80) at src/common/appcmn.cpp:435
#46 0x0000003701bcd45f in wxapp_idle_callback () at src/gtk/app.cpp:213
#47 0x00000038ca02cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#48 0x00000038ca02fc0d in ?? () from /lib64/libglib-2.0.so.0
#49 0x00000038ca02ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#50 0x00000038cc52aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#51 0x0000003701be402d in wxEventLoop::Run (this=0x21107170) at src/gtk/evtloop.cpp:76
#52 0x0000003701c71e38 in wxAppBase::MainLoop (this=0x1f43a8e0) at src/common/appcmn.cpp:312
#53 0x0000000000440d1b in CodeBlocksApp::OnRun (this=0x21a9fc80) at app.cpp:772
#54 0x00000036ffe99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at src/common/init.cpp:448
#55 0x000000000043cc42 in main (argc=1, argv=0x0) at app.cpp:262
Title: Re: wxExecute problems on first start...
Post by: MortenMacFly on May 16, 2012, 02:24:27 pm
Quote from: oBFusCATed on May 16, 2012, 10:27:45 am
Also the first time a try to debug something containing macros, starting the debugger fails, if I hit f8 again it works as expected :(
Has anyone seen such problems?
For this, see here:
http://forums.codeblocks.org/index.php/topic,8809.msg110241.html
I have the same issue, just another effect.
Title: Re: wxExecute problems on first start...
Post by: Folco on May 17, 2012, 04:03:22 pm
(Morten, your link seems to be dead)
Title: Re: wxExecute problems on first start...
Post by: ollydbg on May 17, 2012, 04:16:27 pm
Quote from: Folco on May 17, 2012, 04:03:22 pm
(Morten, your link seems to be dead)
No, the link is only visible to c::b devs.
Title: Re: wxExecute problems on first start...
Post by: MortenMacFly on May 17, 2012, 04:23:43 pm
Quote from: Folco on May 17, 2012, 04:03:22 pm
(Morten, your link seems to be dead)
For the record, this is our "task list":
Quote from: MortenMacFly
Task:
- Fix an issue, that when having a workspace with many targets, macro manager in combination with CC does not work initially with global vars
  • have a ws with many project - all relying on a global var, e.g. "wx"
  • open the workspace
  • quickly hit compile workspace to compile all which would need resolved #wx global vars
  • -> error at the first wx include
  • in the debug log, wait for the final
    "Updating class browser...
    Class browser updated."
  • try again - it works now

This is a serious bug but I don't understand why the macro manager depends on CC or vice versa. Not easy to catch!

Question: does macro manager issue an error if a global var cannot be resolved or access is denied to settings or alike?!
Title: Re: wxExecute problems on first start...
Post by: Folco on May 17, 2012, 10:15:33 pm
Ah ok, thanks.
Title: Re: wxExecute problems on first start...
Post by: ollydbg on May 18, 2012, 02:02:07 am
Quote from: MortenMacFly on May 17, 2012, 04:23:43 pm
Quote from: Folco on May 17, 2012, 04:03:22 pm
(Morten, your link seems to be dead)
For the record, this is our "task list":
Quote from: MortenMacFly
Task:
- Fix an issue, that when having a workspace with many targets, macro manager in combination with CC does not work initially with global vars
  • have a ws with many project - all relying on a global var, e.g. "wx"
  • open the workspace
  • quickly hit compile workspace to compile all which would need resolved #wx global vars
  • -> error at the first wx include
  • in the debug log, wait for the final
    "Updating class browser...
    Class browser updated."
  • try again - it works now

This is a serious bug but I don't understand why the macro manager depends on CC or vice versa. Not easy to catch!

Question: does macro manager issue an error if a global var cannot be resolved or access is denied to settings or alike?!
I just tried several times, but I can't reproduce this issue.

I just open the "ContribPlugins.workspace", and hit "build workspace" quickly, and I have no such issue.
Title: Re: wxExecute problems on first start...
Post by: MortenMacFly on May 18, 2012, 01:31:22 pm
Quote from: ollydbg on May 18, 2012, 02:02:07 am
I just tried several times, but I can't reproduce this issue.
"Nice"... ???

Quote from: ollydbg on May 18, 2012, 02:02:07 am
I just open the "ContribPlugins.workspace", and hit "build workspace" quickly, and I have no such issue.
I have an own workspace that consist of C::B's core, all contrib plugins and additional plugins (so a WS of ~80 targets). Maybe that's why. Try a really, really large WS with as many projects as you have...
Title: Re: wxExecute problems on first start...
Post by: oBFusCATed on May 18, 2012, 01:44:04 pm
For me the bug happens with single project :(
Title: Re: wxExecute problems on first start...
Post by: Jenna on May 18, 2012, 01:48:22 pm
I was just bitten by it the first time (after switching my OS to fedora).
I can just start building a second time and it works.

I'm not sure, but it only seems to happen, if CC is still parsing. I will try if I can reproduce it.
Title: Re: wxExecute problems on first start...
Post by: MortenMacFly on May 18, 2012, 06:42:03 pm
Quote from: jens on May 18, 2012, 01:48:22 pm
I was just bitten by it the first time (after switching my OS to fedora).
I can just start building a second time and it works.
Same for me.
If I am very fast, this can be three times, too.

Quote from: jens on May 18, 2012, 01:48:22 pm
I'm not sure, but it only seems to happen, if CC is still parsing. I will try if I can reproduce it.
Yes - this is definitely related (as I mentioned).

BTW: It seems no-one of the devs really cared so much about the internal report so far. Did you get no notification on that?
Title: Re: wxExecute problems on first start...
Post by: Jenna on May 19, 2012, 08:31:52 am
Quote from: MortenMacFly on May 18, 2012, 06:42:03 pm
BTW: It seems no-one of the devs really cared so much about the internal report so far. Did you get no notification on that?
Which report do you mena ?
The posts in "Remember me" ?
I get notifications for each post in the forum, but not for these as far as I remember.
Title: Re: wxExecute problems on first start...
Post by: MortenMacFly on May 19, 2012, 02:54:30 pm
Quote from: jens on May 19, 2012, 08:31:52 am
Which report do you mena ?
The posts in "Remember me" ?
Yes, those I meant. :-)
Title: Re: wxExecute problems on first start...
Post by: Jenna on May 19, 2012, 04:03:03 pm
I now get notified on new replies.
The cause is, that you only get notification mails for new topics or for topics you have posted in.
Title: Re: wxExecute problems on first start...
Post by: ollydbg on May 22, 2012, 09:38:55 am
Quote from: MortenMacFly on May 17, 2012, 04:23:43 pm
Quote from: Folco on May 17, 2012, 04:03:22 pm
(Morten, your link seems to be dead)
For the record, this is our "task list":
Quote from: MortenMacFly
Task:
- Fix an issue, that when having a workspace with many targets, macro manager in combination with CC does not work initially with global vars
  • have a ws with many project - all relying on a global var, e.g. "wx"
  • open the workspace
  • quickly hit compile workspace to compile all which would need resolved #wx global vars
  • -> error at the first wx include
  • in the debug log, wait for the final
    "Updating class browser...
    Class browser updated."
  • try again - it works now

This is a serious bug but I don't understand why the macro manager depends on CC or vice versa. Not easy to catch!

Question: does macro manager issue an error if a global var cannot be resolved or access is denied to settings or alike?!
Do you think this is the problem caused by wxExecute?

BTW: I see there are some function in CodeCompletion:
Code
Manager::Get()->GetMacrosManager()->ReplaceMacros

Does this function thread safe? I can believe both CC and Compiler plugins will call it sometimes.
Title: Re: wxExecute problems on first start...
Post by: MortenMacFly on May 22, 2012, 10:39:07 am
Quote from: ollydbg on May 22, 2012, 09:38:55 am
Do you think this is the problem caused by wxExecute?
Maybe, you can try to comment the portion where the compiler is called to obtain the macros.


Quote from: ollydbg on May 22, 2012, 09:38:55 am
Code
Manager::Get()->GetMacrosManager()->ReplaceMacros
Does this function thread safe?
I don't know, to be honest. But I doubt its the call from CC that fails - the compiler cannot replace the macros. For CC it seems to work, otherwise you wouldn't have CC working properly.