Re: [cdt-debug-dev] GDB MI problem with out-of-order commands

["Alain Magloire" <alain@xxxxxxx>]

> 
> All,
> 
> We've discovered what appears to be a problem in the GDB
> MI code.  I've verified that the problem exists in the
> 1.0.1 line, but haven't had the chance to test against
> CVS head.
> 
> Apparently, it's possible to get into a state (particularly
> when debugging using GDB server) where a second MI command
> can be issued before the response to the first comes back.
> You end up seeing trace output like the following:
> 
> 1-command
> 2-command
> 1-command-response
> 3-command
> 2-command-response
> 
> ...etc.  In our test case, we were able to reliably reproduce
> a situation where the variables pane failed to update when
> stepping through code after the first out-of-sequence command.
> 
> Taking a look at the GDB MI code, it wasn't apparent to me
> whether or not the implementation was supposed to be able
> to handle command sequences like this.  For our purposes,
> we introduced the following workaround:
> 
> - Create an synchronization object shared by the GDB MI
>   transmit thread and received thread.
> - The tx thread sends a command, then waits on the sync
>   object.
> - When the rx thread receives a response, it signals the
>   sync object.
> 
> This forces the two threads to work together (send response,
> wait for response).  Not the best thing in the world, I think,
> but it clears up the problem with out-of-step commands, and
> corrects the problem with variable updates that we were seeing.
> 

It is done here(RxThread.java):
RxThread.processMIOutput() {
...
		MIResultRecord rr = response.getMIResultRecord();
		if (rr != null) {
			int id = rr.getToken();
			Command cmd = rxQueue.removeCommand(id);

...
			// Notify the waiting command.
			if (cmd != null) {
				synchronized (cmd) {
					// Set the accumulate console Stream
					response.setMIOOBRecords(oobRecords);
					cmd.setMIOutput(response);
					cmd.notifyAll();
				}
			} 
		}
...
}


The RxThread when the response comes back:
	1-command-response
Will look for the Command Queue for a command with that specific ID
	Command cmd = rxQueue.removeCommand(id);
and wake the waiting Command class:
	synchronized (cmd) {
		// Set the accumulate console Stream
		response.setMIOOBRecords(oobRecords);
		cmd.setMIOutput(response);
		cmd.notifyAll();
	}


> The workaround is (obviously) a bit heavy handed.  Has anyone
> else come across this problem before?  If it is indeed a
> problem with GDB MI, I'd prefer to find a real fix to the
> problem, instead of relying on forced synchronization between
> the rx/tx threads.
> 

I'm not exited about this type of synchronisation.  The previous
GDB/MI implementation in CDT was doing this and we try to move
away from it and be asynchrounous as much as possible.
The command will try to synchronize by waiting for a response
for ~10 secs(configurable in preference) and if it is not
awaken(notifyAll()) by the RxThread, it will break out and
continue must however will throw a Timeout exception.

I would say crank up the timeout, in the preference page ~100000
and see what is waiting/blocking for an anwser.