Hi, I've seen a segfault with vmdk, though I haven't investigated further. I suspect it has to do something with vmdk not supporting non-vmdk backing files. It definitely has to do something with vmdk sending a request to a NULL child.
This is a reproducer (not necessarily a minimal one):
$ ./qemu-img create -f vmdk base.vmdk 64M
Formatting 'base.vmdk', fmt=vmdk size=67108864 compat6=off
hwversion=undefined
$ ./qemu-img create -f vmdk -b base.vmdk mid.vmdk
Formatting 'mid.vmdk', fmt=vmdk size=67108864 backing_file=base.vmdk
compat6=off hwversion=undefined
$ ./qemu-img create -f vmdk -b mid.vmdk top.vmdk
Formatting 'top.vmdk', fmt=vmdk size=67108864 backing_file=mid.vmdk
compat6=off hwversion=undefined
$ ./qemu-io -c 'write 0 1M' mid.vmdk
wrote 1048576/1048576 bytes at offset 0
1 MiB, 1 ops; 0.0695 sec (14.379 MiB/sec and 14.3786 ops/sec)
$ echo '
{"execute":"qmp_capabilities"}
{"execute":"blockdev-add",
"arguments":{"node-name":"node0","driver":"vmdk",
"file":{"driver":"file","filename":"top.vmdk"},
"backing":{
"driver":"vmdk","file":{"driver":"file","filename":"mid.vmdk"},
"backing":{
"driver":"vmdk","file":{"driver":"file","filename":"base.vmdk"},
"backing":{"driver":"null-co"}}}}}
{"execute":"block-commit",
"arguments":{"job-id":"commit","device":"node0",
"top":"mid.vmdk","base":"base.vmdk","speed":1}}
{"execute":"job-pause","arguments":{"id":"commit"}}
{"execute":"quit"}' | \
x86_64-softmmu/qemu-system-x86_64 -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
"package": "v2.12.0-1769-g9d0c64bac6-dirty"}, "capabilities": []}}
{"return": {}}
{"return": {}}
{"timestamp": {"seconds": 1530137344, "microseconds": 421127}, "event":
"JOB_STATUS_CHANGE", "data": {"status": "created", "id": "commit"}}
{"timestamp": {"seconds": 1530137344, "microseconds": 421480}, "event":
"JOB_STATUS_CHANGE", "data": {"status": "running", "id": "commit"}}
{"return": {}}
[2] 17059 done echo |
17060 segmentation fault (core dumped)
x86_64-softmmu/qemu-system-x86_64 -qmp stdio
(gdb) bt
#0 0x000055c338ea719d in bdrv_co_preadv (child=0x0,
offset=94296964162136, bytes=10240, qiov=0x7f7a3a4ef9c0, flags=0) at
block/io.c:1361
#1 0x000055c338ea7f22 in bdrv_rw_co_entry (opaque=0x7f7a3a4ef960) at
block/io.c:768
#2 0x000055c338ea7f8b in bdrv_prwv_co (child=child@entry=0x0,
offset=offset@entry=94296964162136, qiov=qiov@entry=0x7f7a3a4ef9c0,
is_write=is_write@entry=false, flags=flags@entry=0) at block/io.c:797
#3 0x000055c338ea8336 in bdrv_preadv (qiov=0x7f7a3a4ef9c0,
offset=94296964162136, child=0x0) at block/io.c:930
#4 0x000055c338ea8336 in bdrv_pread (child=0x0, offset=94296964162136,
buf=buf@entry=0x55c33b6a6610, bytes=bytes@entry=10240) at block/io.c:930
#5 0x000055c338e60c4a in vmdk_read_cid (parent=parent@entry=0,
pcid=pcid@entry=0x7f7a3a4efa44, bs=<optimized out>, bs=<optimized out>)
at block/vmdk.c:259
I don't have the time to investigate this right now, so this mail has to
suffice from my side for now.
Max
signature.asc
Description: OpenPGP digital signature
