On Thu, Nov 26, 2015 at 06:19:46PM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 26, 2015 at 11:26:10AM +0000, Peter Maydell wrote: > > On 19 November 2015 at 13:35, Michael S. Tsirkin <m...@redhat.com> wrote: > > > The following changes since commit > > > 8337c6cbc37c6b2184f41bab3eaff47d5e68012a: > > > > > > Update version for v2.5.0-rc0 release (2015-11-13 17:10:36 +0000) > > > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream > > > > > > for you to fetch changes up to 1c7ba94a184df1eddd589d5400d879568d3e5d08: > > > > > > exec: silence hugetlbfs warning under qtest (2015-11-19 15:26:05 +0200) > > > > > > ---------------------------------------------------------------- > > > vhost, pc: fixes for 2.5 > > > > > > Fixes all over the place. > > > > > > This also re-enables a test we disabled in 2.5 cycle > > > now that there's a way not to get a warning from it. > > > > > > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > > > > Hi; I've just noticed that since this pull was applied the Travis > > builds have been failing: > > https://travis-ci.org/qemu/qemu/builds > > > > The log messages are rather odd but suggest a virtio-user problem: > > So far, it looks like I found a bunch of qemu-char (or possibly glib?) > problems. > This is on Fedora 23. > How to reproduce: > > First, apply this patch: > > vhost-user-test: fix migration overlap test > > Now > > [mst@robin qemu]$ make -j 16 > CC qemu-char.o > LINK x86_64-softmmu/qemu-system-x86_64 > LINK i386-softmmu/qemu-system-i386 > [mst@robin qemu]$ make tests/vhost-user-test > CC tests/vhost-user-test.o > LINK tests/vhost-user-test > > > Run under valgrind: > QTEST_QEMU_BINARY=./x86_64-softmmu/qemu-system-x86_64 valgrind > tests/vhost-user-test > > What seems to happen is that after remove_fd_in_watch, read callback > is still invoked. read fails so it calls close, and close > causes use after free. > > Help would be appreciated.
Here's the log: http://paste.fedoraproject.org/294863/55491614 As you see tcp_chr_close freed a bunch of stuff, and now tcp_chr_read attempts to use it. > -- > MST
