blob: 5a240a1ee32e3557268cc9d5a5fcaf8ac6a12f4a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
debug: 0.873
device: 0.811
graphic: 0.786
performance: 0.776
semantic: 0.630
PID: 0.588
KVM: 0.585
vnc: 0.538
network: 0.508
permissions: 0.477
boot: 0.377
socket: 0.360
other: 0.227
files: 0.215
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:
|