FindTargetsDebugger bypassed on workspace load

[Pecan]

When a workspace is loaded and DebuggerManager::OnProjectActivated is called, FindTargetsDebugger is bypassed because of the statement

Code

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

Code

+    Manager::Get()->RegisterEventSink(cbEVT_PROJECT_OPEN, new Event(this, &DebuggerManager::OnProjectActivated));

solves the problem, since at that call, IsLoadingOrClosing() is false.

Code

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

[oBFusCATed]

What are the steps needed to reproduce this?

[Pecan]

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.

[oBFusCATed]

What are the steps needed to reproduce this?

OK, But what is the problem, uses the wrong configuration, when debugging?

[Pecan]

Yes, of course. It uses the gdb/cdb debugger when it should have used the gdb/mi debugger.

[MortenMacFly]

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

[MortenMacFly]

Code

+    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:

Code

Manager::Get()->RegisterEventSink(cbEVT_PROJECT_ACTIVATE, new Event(this, &DebuggerManager::OnProjectActivated));

??

[Pecan]

Code

+    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:

Code

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.