Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => CodeCompletion redesign => Topic started by: Jenna on January 02, 2013, 01:09:01 pm

Title: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 02, 2013, 01:09:01 pm
I just opened the C::B worksapece and started a rebuild.
C::B hangs after the first cleaning message.
This seems to happen due to the timer-triggered kick-in of the nativeparser.

I attach a backtrace of my attached (hanging) C::B process.
It's without debugging symbols (stripped version of my repo).
C::B is r8710.

On the first look it looks like a deadlock after the call to Manager::Yield(); in void CompilerGCC::BuildStateManagement() .

No time to digg into it deeper at the moment.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 02, 2013, 02:00:21 pm
On the first look it looks like a deadlock after the call to Manager::Yield(); in void CompilerGCC::BuildStateManagement() .
Hmmm... again such a nice one unable to reproduce. But I wonder why calling Yield should lead to a deadlock. Could it be that instead the command issued by CC to obtain the compiler dirs hangs? Can you verify this in the task manager somehow? Especially what command is it? Is this (compiler) executable present?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 02, 2013, 02:43:39 pm
On the first look it looks like a deadlock after the call to Manager::Yield(); in void CompilerGCC::BuildStateManagement() .
But I wonder why calling Yield should lead to a deadlock.

I did not say, that the call to Yield leads to the dealock, but it appears right after it.
I guess Yield allows the pending events to be called (timer-event in this case).
Athe the same moment the BuildManagement has started and CompilerCommandGenerator::Init is called, which clears all its member-variables and reinitializes them.
Yes the compiler exists and the hang is in SetupLinkerOptions, so the call must be either in `wx-config --libs`, `wx-config --libs aui` or `pkg-config --libs gtk+-2.0`.
There might be something done in compilergcc, what blocks the wxExecute for some reason.

I will try to reproduce with a debug-build, so I get a little more information.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 02, 2013, 02:53:20 pm
There might be something done in compilergcc, what blocks the wxExecute for some reason.
I would guess that, too. The direct wxExecute calls are no good IMHO. Some time ago I had implemented a tiny cbProcess class that wraps direct wxExecute calls in a wxThreadHelper and returns the output event based. The class is ready and I wanted to replace the calls in the compiler plugin with that and change the logic to be event based. But its not as easy as I thought, unfortunately and due to conflicts with other changes in the compiler plugin I dropped it... but I still believe this would help.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 03, 2013, 10:54:12 am
A problem might be, that the parser(s) run in (a) thread(s) and indirectly call wxExecute (in ExpandBackticks for example.
Even if wxExecute is a function in wxBase it uses wxGui also.
My guess is, that this might lead to problems, if it is not called from the main-thread.
wxExecute might also call Yield (according to the docu), but this can also be a problem, if it is done recursively (at least if onlyIfNeeded is not set).
I attach a full backtrace, but I don't think it really helps here.
The best way to avoid issues would be to avoid any gui-calls from non-main threads and use events and callbacks there.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 03, 2013, 10:59:05 am
[...]
Even if wxExecute is a function in wxBase it uses wxGui also.
[...]
The best way to avoid issues would be to avoid any gui-calls from non-main threads and use events and callbacks there.
How shall that work? You mean CC should command the core to run wxExecute statements and wait until its signalled to expand backticks, for example?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 03, 2013, 12:01:27 pm
How shall that work? You mean CC should command the core to run wxExecute statements and wait until its signalled to expand backticks, for example?
That would be a solution.
Something like issuing a cbEVENT with the commandline as parameter and a pointer to a callback-function.

This must not necessarily done by the core (but this might be useful for others also), but can also be done by the not threaded part of CC of course.
Something like this might be necessary for the clasbrowserbuilderthread also, but here it would probably lead to tons of messages (large trees), which needs many resources.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 04, 2013, 12:53:58 am
Jens: Is there any chance that you are using gtk+ 3.6.

For me it is almost impossible to rebuild cb's workspace at the moment.

Code
(gdb) thread apply all bt

Thread 7 (Thread 0x7fc561d04700 (LWP 14207)):
#0  0x00007fc56e32d59c in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x00007fc56fa7d893 in wxConditionInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#2  0x00007fc56fa7dda0 in wxSemaphoreInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#3  0x00007fc56f3da87e in ?? ()
#4  0x0000000000f5d701 in ?? ()
#5  0x0000000000f5dd28 in ?? ()
#6  0x00000001df148a98 in ?? ()
#7  0x00007fc54ad69fd0 in ?? ()
#8  0x00000000007894a0 in ?? ()
#9  0x00007fc56fa7e991 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib64/libwx_baseu-2.8.so.0
#10 0x00007fc56afab344 in ?? () from /usr/lib64/libGL.so.1
#11 0x00007fc56e328d96 in start_thread () from /lib64/libpthread.so.0
#12 0x00007fc56e06246d in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x7fc561503700 (LWP 14208)):
#0  0x00007fc56e32d59c in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x00007fc56fa7d893 in wxConditionInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#2  0x00007fc56fa7dda0 in wxSemaphoreInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#3  0x00007fc56f3da87e in ?? ()
#4  0x0000000000000001 in ?? ()
#5  0x0000000000f5dd60 in ?? ()
#6  0x0000000000f5eb60 in ?? ()
#7  0x00007fc56fa7d9d9 in wxMutexInternal::Unlock() () from /usr/lib64/libwx_baseu-2.8.so.0
#8  0x00007fc56fa7e991 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib64/libwx_baseu-2.8.so.0
#9  0x00007fc56afab344 in ?? () from /usr/lib64/libGL.so.1
#10 0x00007fc56e328d96 in start_thread () from /lib64/libpthread.so.0
#11 0x00007fc56e06246d in clone () from /lib64/libc.so.6

Thread 5 (Thread 0x7fc560d02700 (LWP 14209)):
#0  0x00007fc56e32d59c in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x00007fc56fa7d893 in wxConditionInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#2  0x00007fc56fa7dda0 in wxSemaphoreInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#3  0x00007fc56f3da87e in ?? ()
#4  0x0000000000000001 in ?? ()
#5  0x0000000000f5dd98 in ?? ()
#6  0x0000000000f5f500 in ?? ()
#7  0x00007fc56fa7d9d9 in wxMutexInternal::Unlock() () from /usr/lib64/libwx_baseu-2.8.so.0
#8  0x00007fc56fa7e991 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib64/libwx_baseu-2.8.so.0
#9  0x00007fc56afab344 in ?? () from /usr/lib64/libGL.so.1
#10 0x00007fc56e328d96 in start_thread () from /lib64/libpthread.so.0
#11 0x00007fc56e06246d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7fc560501700 (LWP 14210)):
#0  0x00007fc56e32d59c in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x00007fc56fa7d893 in wxConditionInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#2  0x00007fc56fa7dda0 in wxSemaphoreInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#3  0x00007fc56f3da87e in ?? ()
#4  0x0000000000000001 in ?? ()
#5  0x0000000000f5ddd0 in ?? ()
#6  0x0000000000f5fc80 in ?? ()
#7  0x00007fc56fa7d9d9 in wxMutexInternal::Unlock() () from /usr/lib64/libwx_baseu-2.8.so.0
#8  0x00007fc56fa7e991 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib64/libwx_baseu-2.8.so.0
#9  0x00007fc56afab344 in ?? () from /usr/lib64/libGL.so.1
#10 0x00007fc56e328d96 in start_thread () from /lib64/libpthread.so.0
#11 0x00007fc56e06246d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7fc552c29700 (LWP 14236)):
#0  0x00007fc56e32d59c in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x00007fc56fa7d893 in wxConditionInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#2  0x00007fc56fa7dda0 in wxSemaphoreInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#3  0x00007fc552d509e0 in ClassBrowserBuilderThread::Entry (this=0x1bd8210) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/classbrowserbuilderthread.cpp:191
#4  0x00007fc56fa7e991 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib64/libwx_baseu-2.8.so.0
#5  0x00007fc56afab344 in ?? () from /usr/lib64/libGL.so.1
#6  0x00007fc56e328d96 in start_thread () from /lib64/libpthread.so.0
#7  0x00007fc56e06246d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7fc55c23d700 (LWP 14237)):
#0  0x00007fc56e32d59c in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x00007fc56fa7d893 in wxConditionInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#2  0x00007fc56fa7dda0 in wxSemaphoreInternal::Wait() () from /usr/lib64/libwx_baseu-2.8.so.0
#3  0x00007fc56f35be27 in ?? ()
#4  0x000000000267a600 in ?? ()
#5  0x0000000001c8d501 in ?? ()
#6  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7fc573842940 (LWP 14186)):
#0  0x00007fc56e06efae in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00007fc56dff8ed9 in _L_lock_7748 () from /lib64/libc.so.6
#2  0x00007fc56dff7c5d in calloc () from /lib64/libc.so.6
#3  0x00007fc56815efc2 in ?? () from /usr/lib64/libnvidia-tls.so.310.19
#4  0x00007fc56fa48ff4 in wxStringBase::AllocBuffer(unsigned long) () from /usr/lib64/libwx_baseu-2.8.so.0
#5  0x00007fc56fa491bd in wxStringBase::AllocBeforeWrite(unsigned long) () from /usr/lib64/libwx_baseu-2.8.so.0
#6  0x00007fc56fa49fe6 in wxStringBase::AssignCopy(unsigned long, wchar_t const*) () from /usr/lib64/libwx_baseu-2.8.so.0
#7  0x00007fc56fa4a0eb in wxStringBase::operator=(wchar_t) () from /usr/lib64/libwx_baseu-2.8.so.0
#8  0x00007fc56fa1fcb8 in wxFileName::GetPathSeparators(wxPathFormat) () from /usr/lib64/libwx_baseu-2.8.so.0
---Type <return> to continue, or q <return> to quit---
#9  0x00007fc56fa1fe0a in wxFileName::GetPathTerminators(wxPathFormat) () from /usr/lib64/libwx_baseu-2.8.so.0
#10 0x00007fc56fa21436 in wxFileName::SplitPath(wxString const&, wxString*, wxString*, wxString*, wxString*, bool*, wxPathFormat) () from /usr/lib64/libwx_baseu-2.8.so.0
#11 0x00007fc56fa233ba in wxFileName::SplitPath(wxString const&, wxString*, wxString*, wxString*, wxPathFormat) () from /usr/lib64/libwx_baseu-2.8.so.0
#12 0x00007fc56fa23531 in ?? () from /usr/lib64/libwx_baseu-2.8.so.0
#13 0x00007fc56fa23a6a in ?? () from /usr/lib64/libwx_baseu-2.8.so.0
#14 0x00007fc570ac5686 in wxDebugReport::wxDebugReport() () from /usr/lib64/libwx_gtk2u_qa-2.8.so.0
#15 0x0000000000455f19 in CodeBlocksApp::OnFatalException (this=0x7c3a40) at /home/obfuscated/projects/codeblocks/git/src/src/app.cpp:819
#16 0x00007fc56fa832ec in wxFatalSignalHandler () from /usr/lib64/libwx_baseu-2.8.so.0
#17 <signal handler called>
#18 0x00007fc56dff20a3 in malloc_consolidate () from /lib64/libc.so.6
#19 0x00007fc56dff3cc4 in _int_malloc () from /lib64/libc.so.6
#20 0x00007fc56dff6b84 in malloc () from /lib64/libc.so.6
#21 0x00007fc56e02c059 in __alloc_dir () from /lib64/libc.so.6
#22 0x00007fc56afa82da in ?? () from /usr/lib64/libGL.so.1
#23 0x00007fc56afa8a43 in ?? () from /usr/lib64/libGL.so.1
#24 0x00007fc56afa8d0c in ?? () from /usr/lib64/libGL.so.1
#25 0x00007fc56afa8d6a in ?? () from /usr/lib64/libGL.so.1
#26 0x00007fc56af8486a in ?? () from /usr/lib64/libGL.so.1
#27 0x00007fc57364fafb in _dl_fini () from /lib64/ld-linux-x86-64.so.2
#28 0x00007fc56dfaf441 in __run_exit_handlers () from /lib64/libc.so.6
#29 0x00007fc56dfaf495 in exit () from /lib64/libc.so.6
#30 0x00007fc572db4861 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#31 0x00007fc56da7a9d5 in _XError () from /usr/lib64/libX11.so.6
#32 0x00007fc56da77dd7 in ?? () from /usr/lib64/libX11.so.6
#33 0x00007fc56da77e25 in ?? () from /usr/lib64/libX11.so.6
#34 0x00007fc56da78465 in _XEventsQueued () from /usr/lib64/libX11.so.6
#35 0x00007fc56da6961d in XPending () from /usr/lib64/libX11.so.6
#36 0x00007fc572daa6b6 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#37 0x00007fc57121d525 in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0
#38 0x00007fc57121dbf3 in ?? () from /usr/lib64/libglib-2.0.so.0
#39 0x00007fc57121e11a in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#40 0x00007fc57313e927 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#41 0x00007fc57010c528 in wxEventLoop::Run() () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#42 0x00007fc57017fa5b in wxAppBase::MainLoop() () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#43 0x0000000000455cac in CodeBlocksApp::OnRun (this=0x7c3a40) at /home/obfuscated/projects/codeblocks/git/src/src/app.cpp:787
#44 0x00007fc56fa2dcda in wxEntry(int&, wchar_t**) () from /usr/lib64/libwx_baseu-2.8.so.0
#45 0x0000000000453279 in main (argc=8, argv=0x7fffdf149de8) at /home/obfuscated/projects/codeblocks/git/src/src/app.cpp:266


Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 04, 2013, 01:29:53 am
Jens: Is there any chance that you are using gtk+ 3.6.
I use gtk+ 3.4 and 2.24 for C::B I use gtk+2, of course.
There is no wx2.8 with gtk3 available and C::B itself compiles and lnks against gtk+2.

I can reproduce the issue not always but quite often, it's always ExpandBackticks called by CC-timer which hangs.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 04, 2013, 06:33:37 am
I can reproduce the issue not always but quite often, it's always ExpandBackticks called by CC-timer which hangs.
I can't. :( Must be Linux only - maybe because under Windows there is nothing to expand...?! Did you manage to find a way to reproduce it under Windows? Is it really ExpandBackticks only?

Edit: Oh, and BTW: Where does CC call ExpandBackticks? I didn't find it with a quick search...
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 04, 2013, 06:37:40 am
For me it is almost impossible to rebuild cb's workspace at the moment.
In your BT I don-t even see what goes wrong... ???
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 04, 2013, 09:30:28 am
I can reproduce the issue not always but quite often, it's always ExpandBackticks called by CC-timer which hangs.
I can't. :( Must be Linux only - maybe because under Windows there is nothing to expand...?! Did you manage to find a way to reproduce it under Windows? Is it really ExpandBackticks only?

Edit: Oh, and BTW: Where does CC call ExpandBackticks? I didn't find it with a quick search...
CC calls GetCommandGenerator in AddProjectToParser.
The commandgenerator get initiated and calls SetupCompilerOptions, SetupLinkerOptions etc.
And this calls ExpandBackticks.
wxExecute always hangs in wxGUIAppTraits::WaitForChild() or wxPipeInputStream::CanRead().
The latter might be the real issue for some reason I don't know.

I just saw that I forgot to attach the full bt in one of my prior posts.
I attach it here.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 04, 2013, 09:58:25 am
In your BT I don-t even see what goes wrong... ???
The strangest thing is that it happens if I run cb from cb, if I use the run.sh script it works.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 04, 2013, 11:39:53 am
CC calls GetCommandGenerator in AddProjectToParser.
So it means this is the actually command that should be wrapped in an event, or is it the wxExecute call in the compiler? The latter is more hard to do, cause it would change the logic in CC as the call does immediately return w/o a result.

I wonder what's best here:
Actually calling GetCommandGenerator is done to obtain the project include dirs which will trigger wxExecute if backticked expressions are in place. Maybe a better solution is if CC does not use CommandGenerator at all, but evaluates the project / target settings itself, including executing what ever. Another option is to move the method from CommandGenerator to the core and wrap it there... maybe extend project manager.

What would be a good thing to do [tm]?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 04, 2013, 12:02:26 pm
Maybe a better solution is if CC does not use CommandGenerator at all, but evaluates the project / target settings itself, including executing what ever.
Why? Duplicating code is never a good thing.

BTW: I'm looking why the no-change-build of cb is slow. It turned out that the DirectCommands object is recreated tons of times (takes 30-50% time).
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 04, 2013, 01:49:16 pm
BTW: I'm looking why the no-change-build of cb is slow. It turned out that the DirectCommands object is recreated tons of times (takes 30-50% time).
Well it has to at least for each project you compile in the WS for deps (re-)computation, at least. It should instantiate as many times as you have project in your WS. Is that true?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 04, 2013, 01:49:36 pm
Why? Duplicating code is never a good thing.
Better solution?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 04, 2013, 01:56:46 pm
Well it has to at least for each project you compile in the WS for deps (re-)computation, at least. It should instantiate as many times as you have project in your WS. Is that true?
I think it is created for every file. I have to dig more, but my crashing bug is quite annoying and also the code there is a total mess of spaghetti. There is no way someone to understand or modify it easily.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 04, 2013, 02:01:30 pm
also the code there is a total mess of spaghetti. There is no way someone to understand or modify it easily.
Where? Maybe if you tell someone can help...
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 04, 2013, 03:46:47 pm
Where? Maybe if you tell someone can help...
Look at DoRunQueue and BuildStateMachine, also the DirectCommands class is a bit messy :(
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Alpha on January 04, 2013, 04:13:38 pm
Where? Maybe if you tell someone can help...
Look at DoRunQueue and BuildStateMachine, also the DirectCommands class is a bit messy :(
Tell me about it... :-\.  Every time I tried to modify something in there for the XML compiler branch, I came out with a headache.  I think the only way to make the build mechanism readable would be a complete rewrite of it, but that would be a huge amount of work (which is why I have, for the most part, avoided it).
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 04, 2013, 06:03:04 pm
Look at DoRunQueue and BuildStateMachine, also the DirectCommands class is a bit messy :(
Have a look at the attached images... ;-)

Edit: Removed images as they don't seem to help...
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 04, 2013, 06:08:56 pm
WTF... I doubt it will help...

p.s. I hope you know these images will be deleted some day :)
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 04, 2013, 06:32:17 pm
WTF... I doubt it will help...
Sad...

p.s. I hope you know these images will be deleted some day :)
Did that now.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 04, 2013, 10:40:00 pm
Jens: Can you rebuild cb-unix.cpb with c::b compiled and started from another c::b?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 04, 2013, 11:23:10 pm
Jens: Can you rebuild cb-unix.cpb with c::b compiled and started from another c::b?
Yes.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 04, 2013, 11:54:23 pm
Yes.
Hm, have you modified the project to run cb in a terminal?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 05, 2013, 01:05:57 am
Yes.
Hm, have you modified the project to run cb in a terminal?
I only did it in debug-mode and this works (most of the time) if the ExpandBackticks stuff does not kick in.
But in normal mode it hangs reliably if it tries to build the first target.
With console output enabled it also works.
There are several errors shown before the project is loaded:
Code
execvp(-version) failed with error 2!
execvp(-version) failed with error 2!

(codeblocks:22219): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkRadioMenuItem'

(codeblocks:22219): Gtk-CRITICAL **: IA__gtk_radio_menu_item_get_group: assertion `GTK_IS_RADIO_MENU_ITEM (radio_menu_item)' failed

(codeblocks:22219): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkRadioMenuItem'

(codeblocks:22219): Gtk-CRITICAL **: IA__gtk_radio_menu_item_get_group: assertion `GTK_IS_RADIO_MENU_ITEM (radio_menu_item)' failed

after (or while) loading the project the following errors are shown:
Code
(codeblocks:22219): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkRadioMenuItem'

(codeblocks:22219): Gtk-CRITICAL **: IA__gtk_radio_menu_item_get_group: assertion `GTK_IS_RADIO_MENU_ITEM (radio_menu_item)' failed

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

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

The radio-errors/warnings are there for a long time (debugger-menu), the last two assertions are caused by wxExecute as far as I know and are also old.

The first two (execvp) messages are new as far as I can tell.
I will try to dig into it deeper (maybe Null-compiler ?).
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 05, 2013, 01:45:31 am
But in normal mode it hangs reliably if it tries to build the first target.
So, if I understand correctly you are unable to build cb in the described case?

The first two (execvp) messages are new as far as I can tell.
I will try to dig into it deeper (maybe Null-compiler ?).
Yes, they are caused by the xml compiler code, Alpha can you look at them?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 05, 2013, 02:02:45 am
But in normal mode it hangs reliably if it tries to build the first target.
So, if I understand correctly you are unable to build cb in the described case?

The first two (execvp) messages are new as far as I can tell.
I will try to dig into it deeper (maybe Null-compiler ?).
Yes, they are caused by the xml compiler code, Alpha can you look at them?
The error is triggered by bool Compiler::EvalXMLCondition(const wxXmlNode* node) .

This fixes the error, that causes "-version" to be the only command.
The error-message itself will still be there.
I suggest catching the error output and either give a more clear error message or just suppress it.

Code
Index: src/plugins/compilergcc/resources/compilers/options_clang.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/options_clang.xml
+++ src/plugins/compilergcc/resources/compilers/options_clang.xml
@@ -25,7 +25,9 @@
         <Program name="LD"        value="clang++"/>
         <Program name="DBGconfig" value="gdb_debugger:Default"/>
         <Program name="LIB"       value="llvm-ar"/>
-        <if exec="llvm-ar -version">
+        <!-- LIB will be expanded to llvm-ar by Compiler::GetExecName()
+             llvm-ar can not be directly used here, because it can not be evaluated -->
+        <if exec="LIB -version">
             <!-- found, do nothing -->
         </if>
         <else>

And yes I can not compile C::B from a C::B running inside C::B which has no console output (either real console or gdb).
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Alpha on January 05, 2013, 04:10:30 am
Congratulations, you have discovered not one bug, but two!  Compiler::GetExecName() is supposed to return the passed argument, if it is not a macro to be expanded.  Also, it appears that asynchronous use of wxExecute() acts differently on Linux and Windows.
Code
Index: src/sdk/compiler.cpp
===================================================================
--- src/sdk/compiler.cpp (revision 8756)
+++ src/sdk/compiler.cpp (working copy)
@@ -1138,20 +1138,20 @@
         }
         wxSetEnv(wxT("PATH"), path);
         cmd[0] = GetExecName(cmd[0]);
-        if (node->GetAttribute(wxT("regex"), &test))
+
+        long ret;
         {
-            long ret;
-            {
-                wxLogNull logNo;
-                ret = wxExecute(GetStringFromArray(cmd, wxT(" "), false), cmd);
-            }
+            wxLogNull logNo; // do not warn if execution fails
+            ret = wxExecute(GetStringFromArray(cmd, wxT(" "), false), cmd);
+        }
+
+        if (ret != 0) // execution failed
+            val = (node->GetAttribute(wxT("default"), wxEmptyString) == wxT("true"));
+        else if (node->GetAttribute(wxT("regex"), &test))
+        {
             wxRegEx re;
-            if (ret != 0)
+            if (re.Compile(test))
             {
-                val = (node->GetAttribute(wxT("default"), wxEmptyString) == wxT("true"));
-            }
-            else if (re.Compile(test))
-            {
                 for (size_t i = 0; i < cmd.GetCount(); ++i)
                 {
                     if (re.Matches(cmd[i]))
@@ -1162,20 +1162,17 @@
                 }
             }
         }
-        else
-        {
-            wxLogNull logNo;
-            long ret = wxExecute(GetStringFromArray(cmd, wxT(" "), false));
-            val = (ret != 0);
-        }
-        wxSetEnv(wxT("PATH"), origPath);
+        else // execution succeeded (and no regex test given)
+            val = true;
+
+        wxSetEnv(wxT("PATH"), origPath); // restore path
     }
     return val;
 }
 
 wxString Compiler::GetExecName(const wxString& name)
 {
-    wxString ret;
+    wxString ret = name;
     if (name == wxT("C"))
         ret = m_Programs.C;
     else if (name == wxT("CPP"))
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 05, 2013, 07:30:25 am
Does this one:
Congratulations, you have discovered not one bug, but two! [...]
Code
Index: src/sdk/compiler.cpp
...make this one:
Yes, they are caused by the xml compiler code, Alpha can you look at them?
[...]
I suggest catching the error output and either give a more clear error message or just suppress it.
Code
Index: src/plugins/compilergcc/resources/compilers/options_clang.xml
...obsolete?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 05, 2013, 10:16:32 am
Does this one:
Congratulations, you have discovered not one bug, but two! [...]
Code
Index: src/sdk/compiler.cpp
...make this one:
Yes, they are caused by the xml compiler code, Alpha can you look at them?
[...]
I suggest catching the error output and either give a more clear error message or just suppress it.
Code
Index: src/plugins/compilergcc/resources/compilers/options_clang.xml
...obsolete?
The error-message ("execvp(som ething, someargument) failed with error 2!" will still occur, because wxExecute is called for a not existent exe.
It will only be visible from a console, but as it is not meant for the user it should be caught (with a wxArrayString) and dismissed.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 05, 2013, 12:29:37 pm
Also, this is a real problem because the linking with clang is broken. Probably logging some errors here in the normal log will be needed.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 05, 2013, 12:39:13 pm
Also, this is a real problem because the linking with clang is broken. Probably logging some errors here in the normal log will be needed.
There should probably a predefined error-message in the xml-file, which can be shown if the execution fails.
The actual message is not very helpful, at least not for many users, who seem to have problems with more clear messages sometimes  :( .
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 05, 2013, 01:03:38 pm
Yes, this message is printed by wxexecute...
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Alpha on January 05, 2013, 02:10:00 pm
Does this one:
Congratulations, you have discovered not one bug, but two! [...]
Code
Index: src/sdk/compiler.cpp
...make this one:
Yes, they are caused by the xml compiler code, Alpha can you look at them?
[...]
I suggest catching the error output and either give a more clear error message or just suppress it.
Code
Index: src/plugins/compilergcc/resources/compilers/options_clang.xml
...obsolete?
Yes.

It will only be visible from a console, but as it is not meant for the user it should be caught (with a wxArrayString) and dismissed.
With this patch, it should no longer report it to the console; is it still doing that for you?

My original intention behind
Code
<if exec="XXX">
was to allow a conditional to test if a program existed, so in my opinion, there should not be any error message if execution fails.
Also, this is a real problem because the linking with clang is broken.
Clang's linker is not broken (to my knowledge); I had discovered (by accident) that it was possible to install a working Clang without llvm.  The conditional is there so that hopefully Clang will "just work" regardless of user configuration.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 05, 2013, 02:25:24 pm
Clang's linker is not broken (to my knowledge); I had discovered (by accident) that it was possible to install a working Clang without llvm.  The conditional is there so that hopefully Clang will "just work" regardless of user configuration.
I've just upgraded to llvm/clang 3.2 and linking .a files doesn't work anymore. With 3.1 all was fine...

Also the problem is that you never check if the cmd[0]=="". As far as I can see your patch doesn't add such checks. Executing ""+" "+"-version" will never be a good idea...
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 05, 2013, 02:41:07 pm
I've just upgraded to llvm/clang 3.2 and linking .a files doesn't work anymore. With 3.1 all was fine...
Which distro do you use (in case its Windows)? I am looking for a working up-to-date distro of Clang for Windows 32.

I used to use this one:
http://www.ishani.org/web/articles/code/clang-win32/
...but it doesn't work anymore on WinXP/32.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 05, 2013, 02:42:54 pm
The failure message does no longer occur.
I wonder why it was there before.
The bull-logger should have eaten it also I think.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 05, 2013, 03:09:33 pm
Which distro do you use (in case its Windows)?
Gentoo linux in this case, I've not booted windows for quite a long time...
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: ollydbg on January 05, 2013, 03:30:43 pm
I've just upgraded to llvm/clang 3.2 and linking .a files doesn't work anymore. With 3.1 all was fine...
Which distro do you use (in case its Windows)? I am looking for a working up-to-date distro of Clang for Windows 32.

I used to use this one:
http://www.ishani.org/web/articles/code/clang-win32/
...but it doesn't work anymore on WinXP/32.

OT
From mingw64 maillist:
Quote
Hi,

A new LLVM/Clang has been released, with even better C++11 support. Sadly, no important Windows specific things were fixed or added since the previous release (that I know of), so you're still limited to GCC 4.6.3's libstdc++.

The previous 4.6.3 GCC linux64 build was also incompatible with older Linux installs, like Debian stable. This one is buillt on Debian stable, so should work on any non-ancient Linux install. If you need older or 32-bit linux, download the source package and build it yourself :)

Cheers,

Ruben

PS: Download links:
http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/rubenvb/release/
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/


I haven't tried it.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Alpha on January 05, 2013, 04:54:37 pm
I've just upgraded to llvm/clang 3.2 and linking .a files doesn't work anymore. With 3.1 all was fine...
Oh; I was using 3.0 and 3.1 of Clang.

Also the problem is that you never check if the cmd[0]=="". As far as I can see your patch doesn't add such checks. Executing ""+" "+"-version" will never be a good idea...
cmd[0] only became an empty string because of the incorrect behavior in GetExecName() (which the patch fixes).
... but I guess I should add a check in case there is some other situation that has not been considered.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 05, 2013, 05:07:04 pm
... but I guess I should add a check in case there is some other situation that has not been considered.
Yes, this part of the code should be more bulletproofed than the others :)
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Alpha on January 05, 2013, 05:31:55 pm
Yes, this part of the code should be more bulletproofed than the others :)
Code
Index: src/sdk/compiler.cpp
===================================================================
--- src/sdk/compiler.cpp (revision 8758)
+++ src/sdk/compiler.cpp (working copy)
@@ -1151,6 +1151,8 @@
     else if (node->GetAttribute(wxT("exec"), &test))
     {
         wxArrayString cmd = GetArrayFromString(test, wxT(" "));
+        if (cmd.IsEmpty())
+            return false;
         wxString path;
         wxGetEnv(wxT("PATH"), &path);
         const wxString origPath = path;
@@ -1171,20 +1173,21 @@
         }
         wxSetEnv(wxT("PATH"), path);
         cmd[0] = GetExecName(cmd[0]);
-        if (node->GetAttribute(wxT("regex"), &test))
+
+        long ret = -1;
+        if ( !cmd[0].IsEmpty() ) // should never be empty
         {
-            long ret;
-            {
-                wxLogNull logNo;
-                ret = wxExecute(GetStringFromArray(cmd, wxT(" "), false), cmd);
-            }
+            wxLogNull logNo; // do not warn if execution fails
+            ret = wxExecute(GetStringFromArray(cmd, wxT(" "), false), cmd);
+        }
+
+        if (ret != 0) // execution failed
+            val = (node->GetAttribute(wxT("default"), wxEmptyString) == wxT("true"));
+        else if (node->GetAttribute(wxT("regex"), &test))
+        {
             wxRegEx re;
-            if (ret != 0)
+            if (re.Compile(test))
             {
-                val = (node->GetAttribute(wxT("default"), wxEmptyString) == wxT("true"));
-            }
-            else if (re.Compile(test))
-            {
                 for (size_t i = 0; i < cmd.GetCount(); ++i)
                 {
                     if (re.Matches(cmd[i]))
@@ -1195,20 +1198,17 @@
                 }
             }
         }
-        else
-        {
-            wxLogNull logNo;
-            long ret = wxExecute(GetStringFromArray(cmd, wxT(" "), false));
-            val = (ret != 0);
-        }
-        wxSetEnv(wxT("PATH"), origPath);
+        else // execution succeeded (and no regex test given)
+            val = true;
+
+        wxSetEnv(wxT("PATH"), origPath); // restore path
     }
     return val;
 }
 
 wxString Compiler::GetExecName(const wxString& name)
 {
-    wxString ret;
+    wxString ret = name;
     if (name == wxT("C"))
         ret = m_Programs.C;
     else if (name == wxT("CPP"))
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 06, 2013, 01:00:25 am
Should I commit this last patch? What should be the commit message?

p.s. I tried it and it worked, but I've not tested it much.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Alpha on January 06, 2013, 03:59:42 am
Green light for commit.
compiler: fix macro replacement bug; fix wxExecute related bug; add sanity check
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 09, 2013, 12:37:09 am
Jens do you have bt for all threads? (for the original problem)
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 09, 2013, 12:55:09 am
Quote
#0  0x00007ffff421d47f in wxPipeInputStream::CanRead() const () from /usr/lib64/libwx_baseu-2.8.so.0
#1  0x00007ffff488b4fb in wxGUIAppTraits::WaitForChild(wxExecuteData&) () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#2  0x00007ffff421de1e in wxExecute(wchar_t**, int, wxProcess*) () from /usr/lib64/libwx_baseu-2.8.so.0
#3  0x00007ffff421e863 in wxExecute(wxString const&, int, wxProcess*) () from /usr/lib64/libwx_baseu-2.8.so.0
#4  0x00007ffff421b950 in ?? () from /usr/lib64/libwx_baseu-2.8.so.0
#5  0x00007ffff3b823fb in ExpandBackticks (str=...) at /home/obfuscated/projects/codeblocks/git/src/sdk/globals.cpp:849
#6  0x00007ffff3b1534a in CompilerCommandGenerator::SetupCompilerOptions (this=0x26eae40, compiler=0x18c39d0, target=0x1ccd0a0) at /home/obfuscated/projects/codeblocks/git/src/sdk/compilercommandgenerator.cpp:936
#7  0x00007ffff3b0f554 in CompilerCommandGenerator::Init (this=0x26eae40, project=0x1bf2cc0) at /home/obfuscated/projects/codeblocks/git/src/sdk/compilercommandgenerator.cpp:164
#8  0x00007fffe4783483 in CompilerMINGW::GetCommandGenerator (this=0x18c39d0, project=0x1bf2cc0) at /home/obfuscated/projects/codeblocks/git/src/plugins/compilergcc/compilerMINGW.cpp:51
#9  0x00007fffd77d767e in NativeParser::AddCompilerDirs (this=0x17cbd90, project=0x1bf2cc0, parser=0x1cceb60) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/nativeparser.cpp:1988
#10 0x00007fffd77d0717 in NativeParser::DoFullParsing (this=0x17cbd90, project=0x1bf2cc0, parser=0x1cceb60) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/nativeparser.cpp:1044
#11 0x00007fffd77ce021 in NativeParser::CreateParser (this=0x17cbd90, project=0x1bf2cc0) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/nativeparser.cpp:570
#12 0x00007fffd77da80f in NativeParser::OnEditorActivated (this=0x17cbd90, editor=0x24f0240) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/nativeparser.cpp:2605
#13 0x00007fffd77ac5e0 in CodeCompletion::OnEditorActivatedTimer (this=0x17cbd10, event=...) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/codecompletion.cpp:3640
#14 0x00007ffff4219e26 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/lib64/libwx_baseu-2.8.so.0
#15 0x00007ffff4219fab in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from /usr/lib64/libwx_baseu-2.8.so.0
#16 0x00007ffff421a2e4 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/lib64/libwx_baseu-2.8.so.0
#17 0x00007ffff49873ee in wxTimerBase::Notify() () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#18 0x00007ffff48ae1cb in ?? () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#19 0x00007ffff59b85ab in ?? () from /usr/lib64/libglib-2.0.so.0
#20 0x00007ffff59b79e2 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#21 0x00007ffff59b7d28 in ?? () from /usr/lib64/libglib-2.0.so.0
#22 0x00007ffff59b7de4 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#23 0x00007ffff78d8b31 in gtk_main_iteration () from /usr/lib64/libgtk-x11-2.0.so.0
#24 0x00007ffff4892ba5 in wxApp::Yield(bool) () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#25 0x00007ffff488b5c5 in wxGUIAppTraits::WaitForChild(wxExecuteData&) () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#26 0x00007ffff421de1e in wxExecute(wchar_t**, int, wxProcess*) () from /usr/lib64/libwx_baseu-2.8.so.0
#27 0x00007ffff421e863 in wxExecute(wxString const&, int, wxProcess*) () from /usr/lib64/libwx_baseu-2.8.so.0
#28 0x00007ffff421b950 in ?? () from /usr/lib64/libwx_baseu-2.8.so.0
#29 0x00007ffff3b823fb in ExpandBackticks (str=...) at /home/obfuscated/projects/codeblocks/git/src/sdk/globals.cpp:849
#30 0x00007ffff3b1568e in CompilerCommandGenerator::SetupLinkerOptions (this=0x2698bc0, compiler=0x18c39d0, target=0x1cd3ad0) at /home/obfuscated/projects/codeblocks/git/src/sdk/compilercommandgenerator.cpp:965
#31 0x00007ffff3b0f5c7 in CompilerCommandGenerator::Init (this=0x2698bc0, project=0x1bf2cc0) at /home/obfuscated/projects/codeblocks/git/src/sdk/compilercommandgenerator.cpp:165
#32 0x00007fffe4783483 in CompilerMINGW::GetCommandGenerator (this=0x18c39d0, project=0x1bf2cc0) at /home/obfuscated/projects/codeblocks/git/src/plugins/compilergcc/compilerMINGW.cpp:51
#33 0x00007fffd77d767e in NativeParser::AddCompilerDirs (this=0x17cbd90, project=0x1bf2cc0, parser=0x2696830) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/nativeparser.cpp:1988
#34 0x00007fffd77d0717 in NativeParser::DoFullParsing (this=0x17cbd90, project=0x1bf2cc0, parser=0x2696830) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/nativeparser.cpp:1044
#35 0x00007fffd77ce021 in NativeParser::CreateParser (this=0x17cbd90, project=0x1bf2cc0) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/nativeparser.cpp:570
#36 0x00007fffd77a5a4c in CodeCompletion::OnProjectActivated (this=0x17cbd10, event=...) at /home/obfuscated/projects/codeblocks/git/src/plugins/codecompletion/codecompletion.cpp:2385
#37 0x00007fffd77c213b in cbEventFunctor<CodeCompletion, CodeBlocksEvent>::Call (this=0x1b7c650, event=...) at include/cbfunctor.h:35
#38 0x00007ffff3b9967d in Manager::ProcessEvent (this=0x89e730, event=...) at /home/obfuscated/projects/codeblocks/git/src/sdk/manager.cpp:179
#39 0x00007ffff3bb8b52 in PluginManager::NotifyPlugins (this=0x117d880, event=...) at /home/obfuscated/projects/codeblocks/git/src/sdk/pluginmanager.cpp:1445
#40 0x00007ffff3bdb224 in ProjectManager::SetProject (this=0xdd4120, project=0x1bf2cc0, refresh=true) at /home/obfuscated/projects/codeblocks/git/src/sdk/projectmanager.cpp:494
#41 0x00007ffff3bdde36 in ProjectManager::LoadProject (this=0xdd4120, filename=..., activateIt=true) at /home/obfuscated/projects/codeblocks/git/src/sdk/projectmanager.cpp:802
#42 0x000000000049bb09 in MainFrame::DoOpenProject (this=0x16b50b0, filename=..., addToHistory=true) at /home/obfuscated/projects/codeblocks/git/src/src/main.cpp:1826
#43 0x000000000049b781 in MainFrame::OpenGeneric (this=0x16b50b0, filename=..., addToHistory=true) at /home/obfuscated/projects/codeblocks/git/src/src/main.cpp:1775
#44 0x000000000049e343 in MainFrame::OnStartHereLink (this=0x16b50b0, event=...) at /home/obfuscated/projects/codeblocks/git/src/src/main.cpp:2145
#45 0x00007ffff4219e26 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/lib64/libwx_baseu-2.8.so.0
#46 0x00007ffff4219fab in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from /usr/lib64/libwx_baseu-2.8.so.0
#47 0x00007ffff421a2e4 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/lib64/libwx_baseu-2.8.so.0
#48 0x00007ffff4219d92 in wxEvtHandler::ProcessPendingEvents() () from /usr/lib64/libwx_baseu-2.8.so.0
#49 0x00007ffff41972a9 in wxAppConsole::ProcessPendingEvents() () from /usr/lib64/libwx_baseu-2.8.so.0
#50 0x00007ffff4919c2a in wxAppBase::ProcessIdle() () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#51 0x00007ffff489208e in ?? () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#52 0x00007ffff59b79e2 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#53 0x00007ffff59b7d28 in ?? () from /usr/lib64/libglib-2.0.so.0
#54 0x00007ffff59b811a in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#55 0x00007ffff78d8927 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#56 0x00007ffff48a6528 in wxEventLoop::Run() () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#57 0x00007ffff4919a5b in wxAppBase::MainLoop() () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#58 0x0000000000455cec in CodeBlocksApp::OnRun (this=0x7acb80) at /home/obfuscated/projects/codeblocks/git/src/src/app.cpp:787
#59 0x00007ffff41c7cda in wxEntry(int&, wchar_t**) () from /usr/lib64/libwx_baseu-2.8.so.0
#60 0x00000000004532b9 in main (argc=8, argv=0x7fffffffdac8) at /home/obfuscated/projects/codeblocks/git/src/src/app.cpp:266

I doubt that wxExecute is re-entrant function.

This patch makes it 100% reproducible:
Code
diff --git a/src/sdk/globals.cpp b/src/sdk/globals.cpp
index f12fd76..38f672e 100644
--- a/src/sdk/globals.cpp
+++ b/src/sdk/globals.cpp
@@ -841,7 +841,7 @@ wxString ExpandBackticks(wxString& str) // backticks are written in-place to str
         }
         else
         {
-            Manager::Get()->GetLogManager()->DebugLog(F(_T("Caching result of `%s`"), cmd.wx_str()));
+//            Manager::Get()->GetLogManager()->DebugLog(F(_T("Caching result of `%s`"), cmd.wx_str()));
             wxArrayString output;
             if (platform::WindowsVersion() >= platform::winver_WindowsNT2000)
                 wxExecute(_T("cmd /c ") + cmd, output, wxEXEC_NODISABLE);
@@ -849,8 +849,8 @@ wxString ExpandBackticks(wxString& str) // backticks are written in-place to str
                 wxExecute(cmd, output, wxEXEC_NODISABLE);
             bt = GetStringFromArray(output, _T(" "), false);
             // add it in the cache
-            m_Backticks[cmd] = bt;
-            Manager::Get()->GetLogManager()->DebugLog(_T("Cached"));
+            //m_Backticks[cmd] = bt;
+//            Manager::Get()->GetLogManager()->DebugLog(_T("Cached"));
         }
         ret << bt << _T(' ');
         str = str.substr(0, start) + bt + str.substr(end + 1, wxString::npos);
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 09, 2013, 01:01:22 am
Jens do you have bt for all threads? (for the original problem)
No just for the main thread.
I will try to get a bt for all tomorrow.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: Jenna on January 09, 2013, 08:37:11 am
Jens do you have bt for all threads? (for the original problem)
No just for the main thread.
I will try to get a bt for all tomorrow.
I attach two backtraces, one with all threads and a full bt from thread 1.
But nothing didn't change as far as I can see.

But I found one interestant thing:
I have a defunct process with the commandline "gtk2-unicode-re".
That's the script which is called by the "wx-config"-script on fedora ("/usr/lib64/wx/config/gtk2-unicode-release-2.8").
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 09, 2013, 08:53:52 am
I guess you're not using the reproducer patch, because you bt is different.
Also, I guess we're hitting some wxexecute bug here.

Have you tried to use slower running script in the backtick expression? Some script with sleep in it for example?
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: MortenMacFly on January 09, 2013, 09:14:41 am
I guess you're not using the reproducer patch, because you bt is different.
Does that apply to Windows, too? And is it really just commenting the log output and disable caching of backtick'd expressions? ??? I wonder if there is a way to reproduce it on Windows, too.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: oBFusCATed on January 09, 2013, 10:05:13 am
And is it really just commenting the log output and disable caching of backtick'd expressions?
Yes and yes.
But looking at bt provided I think the problem is somewhere else.
Title: Re: CC makes C::B hang in ExpandBackticks
Post by: p2rkw on January 13, 2013, 03:30:28 am
Quote
But looking at bt provided I think the problem is somewhere else.
It may be this bug: http://trac.wxwidgets.org/ticket/12636 but its quite old.

I find out that codeblocks spawned from another codeblocks instance doesn't have opened "/tmp/CODEBLOCKSusername.socket" file.

When I use "Debug" instead of "Build and run" command then new instance of codeblocks doesn't hang.