On Sat, Mar 29, 2014 at 03:02:23AM -0000, Aidan Gauland wrote: > I have been able to consistently reproduce the bug again, and have run > QEMU with Valgrind until OOM. It is unrelated to networking; it is > caused by loading a config file. > > I ran QEMU from Git commit 7f6613cedc59fa849105668ae971dc31004bca1c > under valgrind via... > > valgrind qemu-system-x86_64 -readconfig windows8_throwaway_VM.conf -m 1G > -vga std 2>&1 | tee valgrind.log > > ...where the contents of windows8_throwaway_VM.conf is... > > [drive] > file = "windows8_throwaway_HDD.img" > index = "0" > media = "disk" > if = "virtio" > > [net] > type = "nic" > vlan = "0" > model = "virtio" > > [net] > type = "user" > vlan = "0" > > [rtc] > base = "localtime" > > [machine] > accel = "kvm" > > (I will attach the file in a separate comment, because launchpad appears > to only allow at most one attachment per comment.) > > It does not seem to matter whether VirtIO is used, as I have had this > problem when not using any VirtIO devices, but the Windows guest I had > on-hand was already using it. > > If I invoke QEMU with the equivalent settings all via the command line, > it does not gobble memory (again, regardless of VirtIO). > > qemu-system-x86_64 -drive > file=windows8_throwaway_HDD.img,index=0,media=disk,if=virtio -enable-kvm > -m 1G -vga std -net nic,vlan=0,model=virtio -net user,vlan=0 -rtc > localtime
So this is a problem that only happens under Valgrind? Perhaps this is a valgrind bug. Stefan