sorry, if it was not as clear as it should be...
the assignment you describe is done until old_allocs is NULL (well the
asm-test checks against zero, I've not looked at the macrodef of
QLIST_FOREACH), but in this special case old_allocs points to address
"foobar" *and* old_allocs->next_in_flight.le_next points to same address
"foobar", too, so it will never become NULL and will endless loop...
gdb shows this:
777 QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) {
779 uint64_t end_offset = offset + nb_clusters * s->cluster_size;
780 uint64_t old_offset = old_alloc->offset;
779 uint64_t end_offset = offset + nb_clusters * s->cluster_size;
784 if (end_offset < old_offset || offset > old_end_offset) {
782 old_alloc->nb_clusters * s->cluster_size;
781 uint64_t old_end_offset = old_alloc->offset +
784 if (end_offset < old_offset || offset > old_end_offset) {
777 QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) {
(gdb) print old_alloc
$1 = (QCowL2Meta *) 0x34cb7a0
(gdb) print old_alloc->next_in_flight.le_next
$2 = (struct QCowL2Meta *) 0x34cb7a0
I've not analyzed, what is done within the loop, but there should be a point of
another break-possibility.
I've only understood, that there's something done to expand the allocation of
the qcow2-file, because of some needs within the guest.
because I don't know, how I created that certain disk, I've just started
another VM with a newly created disk. this is done via the
virt-manager-interface of libvirt. if this tool simply calls qemu-img or may
make some api-calls by it's own - I don't know, but if it's as important I'll
strace it.
the disk has a maximum of 32768MB with 0 pre-allocated.
qemu-img info say at the current loop (tried to install the soft again):
file format: qcow2
virtual size: 32G (34359738368 bytes)
disk size: 76M
cluster_size: 65536
if you want more output out of gdb, tell me. the VM currently hangs and
now gdb waits for commands...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/917824
Title:
qemu loops/hangs on extending qcow2-diskspace
Status in QEMU:
New
Status in “qemu-kvm” package in Ubuntu:
Incomplete
Bug description:
system is ubuntu 11-10 with qemu-kvm 0.14.1 (standard dpkg)
while trying to install a software in a winXP-guest on a nearly empty
disk within a qcow2-file, qemu stops answering console and vnc.
gdb on original binary shows, that it doesn't really hang, but seems
to endless loop
recompiling the binary with debugging-symbols shows following problem:
in block/qcow2-cluster.c:777 there's a loop over an allocation-list, but
instead of stopping somewhere, the "next" points to the current one.
QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) { ... }
because I'm not firm with qemu-development, I don't know, which
behaviour would be correct, but simply break this loop doesn't seem to
work: a few moments later the process is again at this point (tried so
by setting the register for comparison to 0)
this situation is continuosly reproducible, but it always take at
least 10-15min to get there, so please, if you have suggestion which I
should try and report, try to give as much suggestions as possible in
one action.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/917824/+subscriptions
