summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/108/KVM/1156632
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/zero-shot/108/KVM/1156632')
-rw-r--r--results/classifier/zero-shot/108/KVM/115663251
1 files changed, 51 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/KVM/1156632 b/results/classifier/zero-shot/108/KVM/1156632
new file mode 100644
index 000000000..2dcf80f8e
--- /dev/null
+++ b/results/classifier/zero-shot/108/KVM/1156632
@@ -0,0 +1,51 @@
+KVM: 0.966
+socket: 0.940
+performance: 0.830
+device: 0.806
+semantic: 0.731
+graphic: 0.726
+debug: 0.726
+other: 0.693
+network: 0.541
+permissions: 0.426
+vnc: 0.391
+boot: 0.326
+PID: 0.310
+files: 0.195
+
+not receiving RESET event after system_reset command causes QMP connection to die
+
+I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection:
+
+1) Connect to QMP 
+2) Sent qmp_capabilities
+3) Receive reply
+4) Send system_reset
+5) Receive reply
+6) close socket
+7) Connect to socket -> connection refused
+
+However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events:
+1) Connect to QMP 
+2) Sent qmp_capabilities
+3) Receive reply
+4) Send system_reset
+5) Receive reply
+6) Receive reply (is a RESET event)
+7) Receive reply (is a RESET event)
+8) close socket
+9) Connect to socket -> ok
+
+I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU?
+
+For what its worth, i'm using Ubuntu 12.10:
+kvm --version
+QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian), Copyright (c) 2003-2008 Fabrice Bellard
+
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+I'm not sure, the current implementation is multi-threaded so I won't hit this bug if its still present. If I can find the time I will make a proof of concept and test if the bug is still present.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+