Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
CC makes C::B hang in ExpandBackticks
Jenna:
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.
MortenMacFly:
--- Quote from: jens on January 02, 2013, 01:09:01 pm ---On the first look it looks like a deadlock after the call to Manager::Yield(); in void CompilerGCC::BuildStateManagement() .
--- End quote ---
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?
Jenna:
--- Quote from: jens on January 02, 2013, 01:09:01 pm ---On the first look it looks like a deadlock after the call to Manager::Yield(); in void CompilerGCC::BuildStateManagement() .
--- End quote ---
--- Quote from: MortenMacFly on January 02, 2013, 02:00:21 pm ---But I wonder why calling Yield should lead to a deadlock.
--- End quote ---
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.
MortenMacFly:
--- Quote from: jens on January 02, 2013, 02:43:39 pm ---There might be something done in compilergcc, what blocks the wxExecute for some reason.
--- End quote ---
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.
Jenna:
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.
Navigation
[0] Message Index
[#] Next page
Go to full version