1 files changed, 62 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1712564 b/results/classifier/118/graphic/1712564
new file mode 100644
index 000000000..486dc8100
--- /dev/null
+++ b/results/classifier/118/graphic/1712564
@@ -0,0 +1,62 @@
+graphic: 0.831
+PID: 0.802
+ppc: 0.725
+device: 0.723
+kernel: 0.720
+socket: 0.684
+vnc: 0.682
+performance: 0.667
+architecture: 0.662
+permissions: 0.655
+assembly: 0.651
+VMM: 0.643
+hypervisor: 0.643
+network: 0.640
+arm: 0.636
+user-level: 0.626
+register: 0.620
+mistranslation: 0.592
+peripherals: 0.586
+debug: 0.579
+semantic: 0.553
+risc-v: 0.552
+x86: 0.526
+TCG: 0.521
+files: 0.514
+boot: 0.466
+virtual: 0.458
+KVM: 0.410
+i386: 0.399
+
+loadvm fails twice in sequence
+
+13:38:23) shorne_: Hello, I was doing some testing with migrations for my OpenRISC SMP patch set, I noticed something that looks like a bug, wondering if someone else wants to confirm
+(13:38:47) shorne_: Basically, calling loadvm 2 times causes crash
+(13:38:54) shorne_:    migration/savevm.c:    qemu_event_set(&mis->main_thread_load_event)
+(13:38:54) stefanha: fam: Here is my take at this change: https://paste.debian.net/982690/
+(13:38:56) shorne_:                             assert(ev->initialized)  - fails inside
+(13:39:32) stefanha: quintela davidgiluk: ^
+(13:41:23) ***davidgiluk looks
+(13:41:40) shorne_: c096358e747 util/qemu-thread-posix.c (Fam Zheng              2017-07-04 20:23:25 +0800 397)     assert(ev->initialized);
+(13:41:51) davidgiluk: shorne_: So you're doing a loadvm to load a snapshot and then again?
+(13:42:02) shorne_: Looks like adding that assert() was done really recently
+(13:42:41) shorne_: yes, just loadvm 'a' ... then wait a bit longer, loadvm 'a' again (confirm clocks go back etc)
+(13:42:50) stefanha: fam: While you're having dinner I'll work on turning my script into a qemu-iotests test case that we can merge.
+(13:44:03) gpiccoli [~gpiccoli@0002093a.user.oftc.net] entered the room.
+(13:44:21) davidgiluk: shorne_: Well, it looks like the c09635 assert is a sanity check to make sure we didn't do anything stupid, and well.....
+(13:44:57) pm215: migration_incoming_get_current() and migration_incoming_state_destroy() seem a bit mismatched
+(13:45:13) davidgiluk: pm215: Yep
+(13:45:46) davidgiluk: pm215: Generally we've thought that an incoming migration normally only happens once - shorne_'s case is the exception
+(13:46:03) shorne_: pm215: yeah, it looked something like that I just had a few seconds to look at today
+(13:46:03) HariharanTS left the room (quit: Ping timeout: 480 seconds).
+(13:46:03) shorne_ is now known as shorne
+(13:48:05) shorne: davidgiluk: pm215: thanks for having a look.  Unfortunately I need to head off to bed and put kids to sleep
+(13:49:11) davidgiluk: shorne: Sleep well, no nightmares about event destroyers....
+(13:49:30) davidgiluk: pm215: Yeh this is fall out from b4b076daf32
+
+Posted:
+migration: Reset rather than destroy main_thread_load_event
+snapshot/tests: Try loadvm twice
+
+Commit 5089e1862fe80b6f23ba4c494e2902cbe3d9d48e
+