[all-commits] [llvm/llvm-project] 72ba78: When SendContinuePacketAndWaitForResponse returns ...

[jimingham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 72ba78c29e923cb6e5d89eb5ea8180bf723188be
      https://github.com/llvm/llvm-project/commit/72ba78c29e923cb6e5d89eb5ea8180bf723188be
  Author: Jim Ingham <jingham at apple.com>
  Date:   2021-05-06 (Thu, 06 May 2021)

  Changed paths:
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    A lldb/test/API/functionalities/gdb_remote_client/TestHaltFails.py

  Log Message:
  -----------
  When SendContinuePacketAndWaitForResponse returns eStateInvalid, don't fetch more packets.

This looks like just an oversight in the AsyncThread function.  It gets a result of
eStateInvalid, and then marks the process as exited, but doesn't set "done" to true,
so we go to fetch another event.  That is not safe, since you don't know when that
extra packet is going to arrive.  If it arrives while you are tearing down the
process, the internal-state-thread might try to handle it when the process in not
in a good state.

Rather than put more effort into checking all the shutdown paths to make sure this
extra packet doesn't cause problems, just don't fetch it.  We weren't going to do
anything useful with it anyway.

The main part of the patch is setting "done = true" when we get the eStateInvalid.
I also added a check at the beginning of the while(done) loop to prevent another error
from getting us to fetch packets for an exited process.

I added a test case to ensure that if an Interrupt fails, we call the process
exited.  I can't test exactly the error I'm fixing, there's no good way to know
that the stop reply for the failed interrupt wasn't fetched.  But at least this
asserts that the overall behavior is correct.

Differential Revision: https://reviews.llvm.org/D101933