blob: 70efaff6e0b2b98863c6304aeba833713cd28ce0 (
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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
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:
|