1 files changed, 54 insertions, 0 deletions
diff --git a/results/classifier/118/debug/2963 b/results/classifier/118/debug/2963
new file mode 100644
index 00000000..70efaff6
--- /dev/null
+++ b/results/classifier/118/debug/2963
@@ -0,0 +1,54 @@
+debug: 0.873
+device: 0.811
+graphic: 0.786
+performance: 0.776
+hypervisor: 0.765
+virtual: 0.713
+semantic: 0.630
+PID: 0.588
+KVM: 0.585
+i386: 0.562
+peripherals: 0.553
+kernel: 0.539
+vnc: 0.538
+architecture: 0.538
+x86: 0.534
+network: 0.508
+risc-v: 0.501
+permissions: 0.477
+register: 0.473
+ppc: 0.461
+user-level: 0.431
+VMM: 0.396
+arm: 0.393
+boot: 0.377
+socket: 0.360
+assembly: 0.311
+TCG: 0.308
+files: 0.215
+mistranslation: 0.185
+
+QEMU crash with `qemu_mutex_unlock_impl: Operation not permitted` during block device operations
+Description of problem:
+We got a crash when I use a blockdev-add command while a blockdev-backup operation was nearly complete. The crash does not reproduce consistently.
+
+This message was printed in the QEMU debug log.
+`qemu: qemu_mutex_unlock_impl: Operation not permitted`
+
+We also collected a coredump at the time of the crash. but, when analyzing the coredump using gdb, the call stack only shows ?? for all frames, making it difficult to diagnose the root cause.
+
+so I have two main questions:
+
+1. Under what circumstances does `qemu_mutex_unlock_impl: Operation not permitted` occur? 
+Is there any known cause or workaround for this kind of crash?
+
+2. What should be done to ensure that the call stack in a coredump is visible? 
+Are there specific build flags or debug symbol requirements we should be aware of?
+We built QEMU with --enable-debug, but the call stack still shows only ?? in gdb when analyzing the core dump.
+Steps to reproduce:
+1. Start a VM with block devices configured.
+2. Begin a blockdev-backup operation.
+3. Near the completion of the blockdev-backup, issue a blockdev-add command for another device.
+4. Observe a crash. (The crash does not reproduce consistently)
+Additional information:
+