Comment 2 for bug 917824

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...