1 files changed, 80 insertions, 0 deletions
diff --git a/results/classifier/105/other/1031920 b/results/classifier/105/other/1031920
new file mode 100644
index 000000000..939c2581b
--- /dev/null
+++ b/results/classifier/105/other/1031920
@@ -0,0 +1,80 @@
+other: 0.849
+instruction: 0.735
+mistranslation: 0.709
+device: 0.672
+semantic: 0.657
+assembly: 0.623
+graphic: 0.603
+network: 0.558
+socket: 0.461
+vnc: 0.412
+boot: 0.392
+KVM: 0.358
+
+Linux user gdbserver does not respond to remote  `Ctrl-C' interrupts
+
+The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver:
+
+$ qemu-arm -g 1234 a.out
+
+and then connecting from gdb:
+
+(gdb) target remote :1234
+Remote debugging using :1234
+[New Remote target]
+[Switching to Remote target]
+0x00008ba8 in _start ()
+(gdb) b main
+Breakpoint 1 at 0x8cb0: file hello.c, line 5.
+(gdb) cont
+Continuing.
+
+Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5
+5	  int n = 0;
+(gdb) l
+1	#include <stdio.h>
+2	
+3	int main (int argc, char **argv)
+4	{
+5	  int n = 0;
+6	
+7	  for (;;) {
+8	     printf ("Hello, World!\n");
+9	     sleep (5);
+10	  }
+(gdb) cont
+Continuing.
+^C^CInterrupted while waiting for the program.
+Give up (and stop debugging it)? (y or n) y
+
+Notice that the `Ctrl-C' interrupts are ignored.
+
+I have encountered that issue recently, and started some analysis.
+
+The issue is due to  the fact that in qemu, gdbstub no longer reads the communication channel once
+the debugged process is resumed with "cont".
+Another way to say that, is that communication with gdb is only possible once the process thread execution
+is re-routed in the gdb handler.
+
+I am working on a fix.
+
+The fix will consist in having an additional thread, launched that the internal gdbserver startup, 
+that will be wakeup when the debugged process is resumed. 
+That thread will be waiting on the communication channel for the eventually incoming CTRL-C request (0x3)
+I start to have promising results but it still needs some testing.
+
+Meanwhile, (this should likely be a separate discussion thread, but is somehow related with the named issue above)  ,
+I also noticed that with multithreaded 
+processes, a breakpoint does not suspend all the threads when it is hit. 
+This is a little bit annoying, and does not match the expected behaviour that is typically seen on a pure native gdb debugging
+session.
+
+Once it is ready I will post a patch to qemu mailing list
+
+Best regards
+Thierry
+
+Has the fix mentioned in comment #1 been included in the QEMU repository?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+