Thanks for reporting this bug and doing the analysis.
Despite your pinpointing, I'm afraid I don't quite understand where you
are saying the problem is. I'm sorry, please bear with me. The
QLIST_FOREACH variables are (var, head, field), so we start with
&s->cluster_allocs as head, assign 'old_alloc' to
s->cluster_allocs.lh_first to begin, use that in the loop, and then on
each iteration we set old_allocs = old_allocs->next_in_flight.le_next.
What are you saying we should be using instead?
can you tell me exactly how to reproduce this, with a precise 'qemu-img
create' command, precise kvm command, and how big the qcow2 image is
when it hangs? Given how reproducible it is for you, I"m surprised I
haven't run into it, so I imagine you must be using different options
than I usually do. I'll try to reproduce with your exact options, so
that I can try on the upstream qemu version to see if this has been
fixed upstream.
Thanks again.
** Changed in: qemu-kvm (Ubuntu)
Importance: Undecided => High
** Changed in: qemu-kvm (Ubuntu)
Status: New => Incomplete
--
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
