DeviceManagerSUT has an implicit assumption that the command prompt will be sent along with an error message. That is, if the agent sends the error message and the next command prompt in separate packets, the prompt will not be consumed along with the message, and so it will be treated as the response to the next command, and future commands and responses will become unsynchronized. We haven't noticed this yet because the Java SUTAgent always appends the prompt to the response to the previous command, and so the DeviceManager reads it all together and ignores the prompt. In the C++ agent, we were sending the prompt as a separate message, and it caused all kinds of failures. DeviceManager should be agnostic as to how many packets it takes to get to the next command prompt, assuming it arrives in a timely fashion.

This ensures that, after reading a warning message, we consume the rest of the available data, including the prompt. I have a unit test which I'll post as a separate patch.

https://tbpl.mozilla.org/?tree=Try&rev=b22c2d2d2983 Seems ok.

Unit test for mozbase to verify my fix. Also fixed up the fake-agent thread and added the final missing step to the initialization procedure, the lack of which would cause test_init to fail intermittently.

Comment on attachment 659365 [details] [diff] [review] Always consume prompt after receiving agent warning Looks good. agentErr seems like a slightly strange variable now. How about commandFailed or something?

Comment on attachment 659367 [details] [diff] [review] Unit test Looks good to me. Note that this should land in m-c's testing/mozbase/mozdevice directory now that bug 723107 is fixed. I might just combine this with your previous patch before committing.

Pushed with suggested change. http://hg.mozilla.org/integration/mozilla-inbound/rev/5b4cd3e706fd