1 files changed, 116 insertions, 0 deletions
diff --git a/results/classifier/108/debug/1030666 b/results/classifier/108/debug/1030666
new file mode 100644
index 00000000..fbb858c8
--- /dev/null
+++ b/results/classifier/108/debug/1030666
@@ -0,0 +1,116 @@
+debug: 0.978
+permissions: 0.959
+performance: 0.953
+socket: 0.945
+semantic: 0.945
+network: 0.942
+other: 0.939
+PID: 0.937
+files: 0.920
+boot: 0.914
+device: 0.904
+graphic: 0.901
+vnc: 0.853
+KVM: 0.824
+
+gdb can't proceed after a breakpoint
+
+Using qemu-1.0.1-windows.zip package from http://lassauge.free.fr/qemu/
+Host: Windows 7 Ultimate 64-bit
+Guest: i386 system running MS-DOS 6.22
+Launch command line:
+  qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234
+Debbugers tried:
+  gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16
+  gdb 7.4 on MinGW
+
+Short description:
+I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work.
+
+Steps to reproduce:
+DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk.
+Data.vfd is a floppy image containing a single program (hello.com).
+The aim is to debug the execution of hello.com with gdb.
+Launch Qemu.
+Launch gdb, an attach to qemu:
+  "target remote localhost:1234"
+I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution:
+  "break *0xf730"
+  "continue"
+In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control.
+Examining the program gives expected results (such as "info reg" or "disassemble").
+At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint.
+The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work.
+
+Note that single-stepping and continue works as expected if it is done after interrupting execution with Ctrl-C.
+
+Triaging old bug tickets ... can you still reproduce this issue with the
+latest version of QEMU (version 2.9)?
+
+Hi,
+
+Thank you for your email, I remember this issue. Unfortunately I don’t have the time to try this right now, but I may be able to get to it in the next couple of weeks.
+
+Regards,
+Legorol
+
+From: Thomas Huth
+Sent: 07 April 2017 14:59
+To: <email address hidden>
+Subject: [Bug 1030666] Re: gdb can't proceed after a breakpoint
+
+Triaging old bug tickets ... can you still reproduce this issue with the
+latest version of QEMU (version 2.9)?
+
+** Changed in: qemu
+       Status: New => Incomplete
+
+-- 
+You received this bug notification because you are subscribed to the bug
+report.
+https://bugs.launchpad.net/bugs/1030666
+
+Title:
+  gdb can't proceed after a breakpoint
+
+Status in QEMU:
+  Incomplete
+
+Bug description:
+  Using qemu-1.1.0-windows.zip package from http://lassauge.free.fr/qemu/
+  Host: Windows 7 Ultimate 64-bit
+  Guest: i386 system running MS-DOS 6.22
+  Launch command line:
+    qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234
+  Debbugers tried:
+    gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16
+    gdb 7.4 on MinGW
+
+  Short description:
+  I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work.
+
+  Steps to reproduce:
+  DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk.
+  Data.vfd is a floppy image containing a single program (hello.com).
+  The aim is to debug the execution of hello.com with gdb.
+  Launch Qemu.
+  Launch gdb, an attach to qemu:
+    "target remote localhost:1234"
+  I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution:
+    "break *0xf730"
+    "continue"
+  In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control.
+  Examining the program gives expected results (such as "info reg" or "disassemble").
+  At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint.
+  The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work.
+
+  Note that single-stepping and continue works as expected if it is done
+  after interrupting execution with Ctrl-C.
+
+To manage notifications about this bug go to:
+https://bugs.launchpad.net/qemu/+bug/1030666/+subscriptions
+
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+