From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LV6IF-0003Rr-3z for qemu-devel@nongnu.org; Thu, 05 Feb 2009 10:37:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LV6IE-0003R7-MD for qemu-devel@nongnu.org; Thu, 05 Feb 2009 10:37:30 -0500 Received: from [199.232.76.173] (port=41775 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LV6IE-0003Qz-CX for qemu-devel@nongnu.org; Thu, 05 Feb 2009 10:37:30 -0500 Received: from mx2.redhat.com ([66.187.237.31]:49340) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LV6ID-0002Rb-RI for qemu-devel@nongnu.org; Thu, 05 Feb 2009 10:37:30 -0500 Date: Thu, 5 Feb 2009 17:34:34 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [BUG] Regression in networking code (SIGSEGV) Message-ID: <20090205153434.GB20268@redhat.com> References: <497790E0.7050905@mail.berlios.de> <20090122073800.GK27675@redhat.com> <497B8171.5040409@mail.berlios.de> <20090124215346.GH19498@hall.aurel32.net> <497CD9C2.4010305@mail.berlios.de> <20090126062919.GD15778@redhat.com> <4986020F.4010200@mail.berlios.de> <20090202163806.GA29674@redhat.com> <498983A0.1010807@mail.berlios.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <498983A0.1010807@mail.berlios.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: QEMU Developers On Wed, Feb 04, 2009 at 01:01:36PM +0100, Stefan Weil wrote: > Hi, > > of course. But I found a simple way to reproduce the bug, so I think > this new way is simpler to handle than tcpreplay: > > Host: amd64, debian 5.0 (I think others will do, too) > Guest: i686, debian 4.0 (I think others will do, too) > > The host must export an NFS filesystem (/tftpboot in my tests). > The guest must be able to mount this NFS filesystem using special options. > > Start the guest (hda.img contains a minimal debian 4.0 installation): > $ i386-softmmu/qemu -m 512 -hda ~/hda.img > > Mount host NFS on guest: > $ mount 10.0.2.2:/tftpboot /mnt -o > proto=udp,rsize=4096,wsize=4096,nointr,nolock,nfsvers=2 > > Copy files from host NFS to host NFS on guest: > $ cp /mnt/malta-le/usr/lib/libstdc++.so.6.0.8 /mnt/malta-le/tmp > > In my tests, the file to copy has 1164392 bytes, the guest creates > the destination file with 0 bytes and crashs. > > The NFS mount options are identical to the options used by Linux NFS root > but different to those used by default. With default NFS options, there > is no crash, > so this explains why I get crashs in my NFS root tests but had difficulties > to get a crash with other network operations. > I know that proto=udp is important but did not check many other > combinations. > > With malta and other mips guests, the crash can be reproduced in the > same way, > so I am now fairly sure that any guest (on any host) will crash like this. > Cool, I can reproduce it now! Can you try the patch below? Signed-off-by: Gleb Natapov diff --git a/qemu/slirp/ip_input.c b/qemu/slirp/ip_input.c index e7f2756..f00a2e8 100644 --- a/qemu/slirp/ip_input.c +++ b/qemu/slirp/ip_input.c @@ -393,7 +393,7 @@ insert: */ if (m->m_flags & M_EXT) { int delta; - delta = (char *)ip - m->m_dat; + delta = (char *)q - m->m_dat; q = (struct ipasfrag *)(m->m_ext + delta); } -- Gleb.