Skip to main content
summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMarc Khouzam2017-01-23 09:25:41 -0500
committerGerrit Code Review @ Eclipse.org2017-01-25 15:50:22 -0500
commit9526f139622e2a73cede8db90078fe48d2f8f516 (patch)
tree79757b3c5358dce525db3e64bf7e352dd808f371
parent625dfd8304bb0c3a0148a34314ab76ed8428dd47 (diff)
downloadorg.eclipse.cdt-9526f139622e2a73cede8db90078fe48d2f8f516.tar.gz
org.eclipse.cdt-9526f139622e2a73cede8db90078fe48d2f8f516.tar.xz
org.eclipse.cdt-9526f139622e2a73cede8db90078fe48d2f8f516.zip
Bug 507950 - Answer query on MI channel to avoid GDB waiting forever
With GDB 7.12, it is possible to receive queries on the dedicated MI channel. This channel is not accessible or shown to the user so if we don't answer, GDB will wait forever. This patch blindly answers 'y' to any query on the MI channel unless it has already been answered automatically (which happens when we don't use the full console). Change-Id: I0e208fc3495ce6ba57b3e477661f47e50680fd88 (cherry picked from commit add2a1462852ff27b7c28f1349478281aacf10a0)
-rw-r--r--dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/MIRunControlEventProcessor_7_0.java14
1 files changed, 14 insertions, 0 deletions
diff --git a/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/MIRunControlEventProcessor_7_0.java b/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/MIRunControlEventProcessor_7_0.java
index be1a194f16..9836500b73 100644
--- a/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/MIRunControlEventProcessor_7_0.java
+++ b/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/MIRunControlEventProcessor_7_0.java
@@ -19,6 +19,7 @@ import java.util.regex.Matcher;
import java.util.regex.Pattern;
import org.eclipse.cdt.dsf.concurrent.ConfinedToDsfExecutor;
+import org.eclipse.cdt.dsf.concurrent.ImmediateDataRequestMonitor;
import org.eclipse.cdt.dsf.datamodel.DMContexts;
import org.eclipse.cdt.dsf.debug.service.IProcesses.IProcessDMContext;
import org.eclipse.cdt.dsf.debug.service.IProcesses.IThreadDMContext;
@@ -39,6 +40,7 @@ import org.eclipse.cdt.dsf.mi.service.command.commands.MIExecReturn;
import org.eclipse.cdt.dsf.mi.service.command.commands.MIExecStep;
import org.eclipse.cdt.dsf.mi.service.command.commands.MIExecStepInstruction;
import org.eclipse.cdt.dsf.mi.service.command.commands.MIExecUntil;
+import org.eclipse.cdt.dsf.mi.service.command.commands.RawCommand;
import org.eclipse.cdt.dsf.mi.service.command.events.MIBreakpointHitEvent;
import org.eclipse.cdt.dsf.mi.service.command.events.MIEvent;
import org.eclipse.cdt.dsf.mi.service.command.events.MIFunctionFinishedEvent;
@@ -328,7 +330,19 @@ public class MIRunControlEventProcessor_7_0
MIEvent<?> event = createEvent("signal-received", exec); //$NON-NLS-1$
fCommandControl.getSession().dispatchEvent(event, fCommandControl.getProperties());
}
+ } else if (stream.getCString().indexOf("(y or n)") != -1 && //$NON-NLS-1$
+ stream.getCString().indexOf("[answered ") == -1) {//$NON-NLS-1$
+ // We have a query on MI that was not automatically answered by GDB!.
+ // That is not something GDB should do.
+ // The user cannot answer since it is on MI, so we need to answer
+ // ourselves. If we don't GDB will hang forever, waiting for that
+ // answer. We always answer 'yes' although
+ // we can't be sure it is the right answer, but it is better
+ // than simply hanging there forever.
+ fCommandControl.queueCommand(new RawCommand(fControlDmc, "y"), //$NON-NLS-1$
+ new ImmediateDataRequestMonitor<MIInfo>());
}
+
}
}
}

Back to the top