blob: 766cd46f1436febb7f7a7ac8ad9c1c7c218eea21 (
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
virtual: 0.908
user-level: 0.906
graphic: 0.896
performance: 0.862
files: 0.861
mistranslation: 0.857
KVM: 0.836
semantic: 0.816
device: 0.812
architecture: 0.805
PID: 0.805
ppc: 0.792
hypervisor: 0.791
TCG: 0.776
debug: 0.770
vnc: 0.735
kernel: 0.729
VMM: 0.728
permissions: 0.696
network: 0.692
socket: 0.682
risc-v: 0.670
peripherals: 0.669
register: 0.645
i386: 0.640
arm: 0.638
boot: 0.601
assembly: 0.600
x86: 0.488
qcow2-refcount: qemu-io crashes on 'discard' command
qemu-io is killed by SIGIOT at the 'discard' command on the image having no refcount information.
Sequence:
1. Unpack test.img and backing_img.qed in the same directory (see the attached archives for images)
2. Make a copy of test.img to copy.img (qemu-io modifies the image before being kill, therefore the image backup is necessary)
3. Run the command
qemu-io copy.img -c 'discard 2210816 2856448'
Result: qemu-io is killed by SIGIOT with the reason:
qemu-io: block/qcow2-refcount.c:468: update_refcount_discard: Assertion `d->bytes + length == new_end - new_start' failed.
The image was generated by the image fuzzer.
qemu.git HEAD: 1d80eb7a680d
FWIW:
While trying to restore (apply) a snapshot on a Windows VM (ie: qemu-img snapshot -a snapshotname windows.qcow2 where the image file is 150gb in size,) I got the above error:
qemu-img: /build/buildd/qemu-2.0.0+dfsg/block/qcow2-refcount.c:467: update_refcount_discard: Assertion `d->bytes + length == new_end - new_start' failed.
(My VM is now broken.)
This is the only reference that I found using Google.
HTH
I sent a patch that fixes the original problem that Maria reported. It's hard to say whether this is the same problem as you saw, Sam, but it's quite possible.
Fix has been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ecbda7a22576591a84
... so I think it should be OK now to mark this ticket as fixed.
|