diff options
author | Marc Khouzam | 2017-01-23 14:25:41 +0000 |
---|---|---|
committer | Gerrit Code Review @ Eclipse.org | 2017-01-25 20:50:22 +0000 |
commit | 9526f139622e2a73cede8db90078fe48d2f8f516 (patch) | |
tree | 79757b3c5358dce525db3e64bf7e352dd808f371 | |
parent | 625dfd8304bb0c3a0148a34314ab76ed8428dd47 (diff) | |
download | org.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.java | 14 |
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 be1a194f16f..9836500b73b 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>()); } + } } } |