On 27 October 2014 15:13, Paolo Bonzini <pbonz...@redhat.com> wrote: > The following changes since commit e40830afa1cff3ffdc37bdfdd40d80860074636c: > > Merge remote-tracking branch 'remotes/mdroth/tags/qga-pull-2014-10-22-tag' > into staging (2014-10-22 21:42:33 +0100) > > are available in the git repository at: > > > git://github.com/bonzini/qemu.git tags/for-upstream
This is giving me test failures on my 32 bit ARM board, which manifest as glibc complaints: /x86_64/virtio/rng/pci/hotplug: *** glibc detected *** x86_64-softmmu/qemu-system-x86_64: corrupted double-linked list: 0x02383c10 *** I've been able to repro these on an x86-64 box as valgrind complaints: $ cat /tmp/qemu-system-x86_64 #!/bin/sh -e exec valgrind "$(pwd)"/x86_64-softmmu/qemu-system-x86_64 "$@" $ MALLOC_PERTURB_=180 QTEST_QEMU_BINARY=/tmp/qemu-system-x86_64 gtester -k --verbose -m=quick tests/virtio-rng-test TEST: tests/virtio-rng-test... (pid=15850) ==15852== Memcheck, a memory error detector ==15852== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==15852== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==15852== Command: /home/petmay01/linaro/qemu-for-merges/build/all/x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-15850.sock,nowait -qtest-log /dev/null -qmp unix:/tmp/qtest-15850.qmp,nowait -machine accel=qtest -display none -device virtio-rng-pci ==15852== /x86_64/virtio/rng/pci/nop: OK /x86_64/virtio/rng/pci/hotplug: ==15852== Invalid read of size 4 ==15852== at 0x41A400: object_unref (object.c:716) ==15852== by 0x41A5FD: object_release_link_property (object.c:1228) ==15852== by 0x41A497: object_unref (object.c:367) ==15852== by 0x41A8E3: object_property_del (object.c:800) ==15852== by 0x32AD9D: acpi_pcihp_eject_slot (pcihp.c:139) ==15852== by 0x1F1DD0: access_with_adjusted_size (memory.c:480) ==15852== by 0x1F7746: io_mem_write (memory.c:1122) ==15852== by 0x1B8B72: address_space_rw (exec.c:2145) ==15852== by 0x1EA6E0: cpu_outb (ioport.c:67) ==15852== by 0x1EC05F: qtest_read (qtest.c:296) ==15852== by 0x2DB6EF: tcp_chr_read (qemu-char.c:304) ==15852== by 0x53F6CE4: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0) ==15852== Address 0x19146870 is 32 bytes inside a block of size 96 free'd ==15852== at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==15852== by 0x41A497: object_unref (object.c:367) ==15852== by 0x41A8E3: object_property_del (object.c:800) ==15852== by 0x3539D7: bus_unparent (qdev.c:666) ==15852== by 0x41A598: object_finalize_child_property (object.c:1079) ==15852== by 0x41A8E3: object_property_del (object.c:800) ==15852== by 0x353368: device_unparent (qdev.c:1160) ==15852== by 0x41A598: object_finalize_child_property (object.c:1079) ==15852== by 0x41A8E3: object_property_del (object.c:800) ==15852== by 0x32AD9D: acpi_pcihp_eject_slot (pcihp.c:139) ==15852== by 0x1F1DD0: access_with_adjusted_size (memory.c:480) ==15852== by 0x1F7746: io_mem_write (memory.c:1122) ==15852== ** ERROR:/home/petmay01/linaro/qemu-for-merges/qom/object.c:716:object_unref: assertion failed: (obj->ref > 0) I'm in the process of testing whether this is actually introduced by this set of patches or if they just happened to disturb something to the point where it caused glibc on the 32 bit box to complain. -- PMM
