wxExecute problems on first start...

[oBFusCATed]

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

[MortenMacFly]

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.

[Folco]

(Morten, your link seems to be dead)

[ollydbg]

(Morten, your link seems to be dead)

No, the link is only visible to c::b devs.

[MortenMacFly]

(Morten, your link seems to be dead)

For the record, this is our "task list":

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?!

[Folco]

Ah ok, thanks.

[ollydbg]

(Morten, your link seems to be dead)

For the record, this is our "task list":

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.

[MortenMacFly]

I just tried several times, but I can't reproduce this issue.

"Nice"...

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

[oBFusCATed]

For me the bug happens with single project

[Jenna]

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.

[MortenMacFly]

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.

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?

[Jenna]

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.

[MortenMacFly]

Which report do you mena ?
The posts in "Remember me" ?

Yes, those I meant. :-)

[Jenna]

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.

[ollydbg]

(Morten, your link seems to be dead)

For the record, this is our "task list":

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.