summaryrefslogtreecommitdiffstats
path: root/scripts/device-crash-test
diff options
context:
space:
mode:
authorJohn Snow2021-11-11 15:37:15 +0100
committerJohn Snow2021-11-16 20:26:36 +0100
commitf26bd6ff21df2f1d155ca17eef360423b706ab7f (patch)
tree2b6702e32eaac8f40ae2fa3f8230fbc1f0520439 /scripts/device-crash-test
parentMerge tag 'm68k-for-6.2-pull-request' of git://github.com/vivier/qemu-m68k in... (diff)
downloadqemu-f26bd6ff21df2f1d155ca17eef360423b706ab7f.tar.gz
qemu-f26bd6ff21df2f1d155ca17eef360423b706ab7f.tar.xz
qemu-f26bd6ff21df2f1d155ca17eef360423b706ab7f.zip
python/aqmp: Fix disconnect during capabilities negotiation
If we receive ConnectionResetError (ECONNRESET) while attempting to perform capabilities negotiation -- prior to the establishment of the async reader/writer tasks -- the disconnect function is not aware that we are in an error pathway. As a result, when attempting to close the StreamWriter, we'll see the same ConnectionResetError that caused us to initiate a disconnect in the first place, which will cause the disconnect task itself to fail, which emits a CRITICAL logging event. I still don't know if there's a smarter way to check to see if an exception received at this point is "the same" exception as the one that caused the initial disconnect, but for now the problem can be avoided by improving the error pathway detection in the exit path. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20211111143719.2162525-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Diffstat (limited to 'scripts/device-crash-test')
0 files changed, 0 insertions, 0 deletions