From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nix <nix@esperi.org.uk>
Subject: Re: usb_add crashes stable kvm-0.11.0
Date: Thu, 03 Dec 2009 00:27:04 +0000
Message-ID: <87fx7soqav.fsf@spindle.srvr.nix>
References: <87skbzvdgd.fsf@spindle.srvr.nix> <4B125051.6010506@redhat.com>
	<87k4x9saqn.fsf@spindle.srvr.nix> <4B1283F5.5060204@redhat.com>
	<877ht9rmoo.fsf_-_@spindle.srvr.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kvm@vger.kernel.org
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from icebox.esperi.org.uk ([81.187.191.129]:39834 "EHLO
	mail.esperi.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750759AbZLCA1R (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 2 Dec 2009 19:27:17 -0500
In-Reply-To: <877ht9rmoo.fsf_-_@spindle.srvr.nix> (nix@esperi.org.uk's message of "Sun, 29 Nov 2009 22:27:51 +0000")
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 29 Nov 2009, nix@esperi.org.uk spake thusly:

> One qemu-kvm-specific bug, definitely non-kernel-related, is this crash,
> frequently encountered when hotadding more than one USB device (to an XP
> guest, as it happens, but that doesn't look relevant here):

I also see a crash when using -usbdevice on the command line. Symptoms
are a very long pause instead of booting, and then (in an XP guest,
immediately after the windows desktop appears; so I suspect the
instant the guest tries to probe for USB devices):

*** glibc detected *** /usr/bin/qemu: corrupted double-linked list: 0x0000000002908ce0 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f87cc91a505]
/lib/libc.so.6[0x7f87cc91d96d]
/lib/libc.so.6(__libc_malloc+0x6e)[0x7f87cc91ef1e]
/usr/bin/qemu[0x47037e]
/usr/bin/qemu[0x423585]
/usr/bin/qemu[0x42366f]
/usr/bin/qemu[0x43e620]
/usr/bin/qemu[0x4c73e8]
/usr/bin/qemu[0x40a274]
/usr/bin/qemu[0x421e6a]
/usr/bin/qemu[0x40e7f5]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f87cc8c8a7d]
/usr/bin/qemu[0x407d29]
======= Memory map: ========

malloc() or overrun trouble.

Fixed by c4c0e236beabb9de5ff472f77aeb811ec5484615, with the caveat that
the 2048-byte buffer provided by this commit is nowhere near large
enough: I have seen 4104 bytes coming back from an ipod nano 5 (thanks
to the overrun detection also added by that commit). So I've boosted it
to 8192 here, and it seems to work (albeit killingly slowly).