When a workspace is loaded and DebuggerManager::OnProjectActivated is called, FindTargetsDebugger is bypassed because of the statement
void DebuggerManager::FindTargetsDebugger()
{
if (Manager::Get()->GetProjectManager()->IsLoadingOrClosing())
return;
Thus, the correct debugger is not setup for the project, since IsLoadingOrClosing() is *always* true during OnProjectActivated for workspace loading. (At some point, CB code was changed to leave m_IsLoadingProject at true during OnProjectActivated to avoid a CC problem).
Adding
+ Manager::Get()->RegisterEventSink(cbEVT_PROJECT_OPEN, new Event(this, &DebuggerManager::OnProjectActivated));
solves the problem, since at that call, IsLoadingOrClosing() is false.
Index: src/sdk/debuggermanager.cpp
===================================================================
--- src/sdk/debuggermanager.cpp (revision 8647)
+++ src/sdk/debuggermanager.cpp (working copy)
@@ -674,6 +674,7 @@
{
typedef cbEventFunctor<DebuggerManager, CodeBlocksEvent> Event;
Manager::Get()->RegisterEventSink(cbEVT_PROJECT_ACTIVATE, new Event(this, &DebuggerManager::OnProjectActivated));
+ Manager::Get()->RegisterEventSink(cbEVT_PROJECT_OPEN, new Event(this, &DebuggerManager::OnProjectActivated));
Manager::Get()->RegisterEventSink(cbEVT_BUILDTARGET_SELECTED, new Event(this, &DebuggerManager::OnTargetSelected));
Manager::Get()->RegisterEventSink(cbEVT_SETTINGS_CHANGED, new Event(this, &DebuggerManager::OnSettingsChanged));
Manager::Get()->RegisterEventSink(cbEVT_PLUGIN_LOADING_COMPLETE,
svn build rev 8647 (2012-12-09 23:28:42) gcc 4.3.1 Windows/unicode - 32 bit
What are the steps needed to reproduce this?
Quote from: oBFusCATed on December 18, 2012, 03:15:03 PM
What are the steps needed to reproduce this?
Use a workspace with at least two projects.
Place a breakpoint at the first statement of FindTargetsDebugger.
(faster if you use asm("int3"); )
Load the workspace. Note that the rest of FindTargetsDebugger never gets executed.
Quote from: oBFusCATed on December 18, 2012, 03:15:03 PM
What are the steps needed to reproduce this?
OK, But what is the problem, uses the wrong configuration, when debugging?
Yes, of course. It uses the gdb/cdb debugger when it should have used the gdb/mi debugger.
Quote from: Pecan on December 19, 2012, 12:27:09 PM
Yes, of course. It uses the gdb/cdb debugger when it should have used the gdb/mi debugger.
I think Pecan is right - I've tried with a debug output and I can reproduce. Looking at the patch it won't break anything I guess - but I did
not try yet if it works (but I guess Pecan did... ;-)).
Quote from: Pecan on December 18, 2012, 02:45:43 PM
+ Manager::Get()->RegisterEventSink(cbEVT_PROJECT_OPEN, new Event(this, &DebuggerManager::OnProjectActivated));
solves the problem, since at that call, IsLoadingOrClosing() is false.
One question: Should this not
replace this:
Manager::Get()->RegisterEventSink(cbEVT_PROJECT_ACTIVATE, new Event(this, &DebuggerManager::OnProjectActivated));??
Quote from: MortenMacFly on December 19, 2012, 05:52:42 PM
Quote from: Pecan on December 18, 2012, 02:45:43 PM
+ Manager::Get()->RegisterEventSink(cbEVT_PROJECT_OPEN, new Event(this, &DebuggerManager::OnProjectActivated));
solves the problem, since at that call, IsLoadingOrClosing() is false.
One question: Should this not replace this:
Manager::Get()->RegisterEventSink(cbEVT_PROJECT_ACTIVATE, new Event(this, &DebuggerManager::OnProjectActivated));
??
I did not simple want to replace cbCVT_PROJECT_ACTIVATED because of all the unknown conditions now existing around those project events.
It used to be that cbCVT_PROJECT_ACTIVATED was called twice, once with a null project pointer (meaning ACTIVATING) and once with a valid pointer (meaning NOW ACTIVATED).
We now have a new condition (since the code was modified to accomodate CC) and an event cbEVT_PROJECT_OPEN which now means what the second cbEVT_PROJECT_ACTIVATED used to mean.
So I took the cautious (or cowardly) way out.
Edit: and yes, I tested it for days before proposing the fix.