diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/917824')
| -rw-r--r-- | results/classifier/zero-shot/108/other/917824 | 88 |
1 files changed, 88 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/917824 b/results/classifier/zero-shot/108/other/917824 new file mode 100644 index 000000000..a0b2f43ee --- /dev/null +++ b/results/classifier/zero-shot/108/other/917824 @@ -0,0 +1,88 @@ +debug: 0.857 +other: 0.845 +vnc: 0.843 +permissions: 0.835 +socket: 0.820 +graphic: 0.816 +PID: 0.816 +semantic: 0.810 +device: 0.796 +performance: 0.794 +KVM: 0.794 +boot: 0.764 +network: 0.733 +files: 0.724 + +qemu loops/hangs on extending qcow2-diskspace + +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. + +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. + +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... + + +sorry forgot the requested cmdline of kvm: +kvm -mem-path /VM/tmp -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name winxp -uuid 1c4f4992-9212-4b4c-a14d-25f2f3f28ed2 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x6 -drive file=/VM/winxp/lw-c.img,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/VM/winxp/lw-t.img,if=none,id=drive-ide0-0-1,snapshot=on,format=qcow2 -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/VM/winxp/lw-d.img,if=none,id=drive-ide0-1-1,format=qcow2 -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -drive file=/VM/winxp/lw-p.img,if=none,id=drive-scsi0-0-0,format=qcow2 -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=13,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:00:c1:a3:f4:45,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:3 -vga std -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +the disk, on which the soft should be installed is that one on the emulated scsi-controller + + +Are you able to reproduce this either with an Ubuntu guest, or on a 12.04 (Precise) host? + +sorry, currently I'm busy and there's too much time gone, that I can check the things in a quick way. I'll try it, when I'm less busy, but this will probably take some weeks... + + +Marking this bug invalid. If you can still reproduce it, please reply to let us know. + |