From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUgSA-0000nL-HG for qemu-devel@nongnu.org; Wed, 04 Feb 2009 07:02:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUgS8-0000jx-3S for qemu-devel@nongnu.org; Wed, 04 Feb 2009 07:02:01 -0500 Received: from [199.232.76.173] (port=33668 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUgS7-0000jX-Mw for qemu-devel@nongnu.org; Wed, 04 Feb 2009 07:01:59 -0500 Received: from moutng.kundenserver.de ([212.227.126.188]:57108) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUgS6-0005dl-VZ for qemu-devel@nongnu.org; Wed, 04 Feb 2009 07:01:59 -0500 Message-ID: <498983A0.1010807@mail.berlios.de> Date: Wed, 04 Feb 2009 13:01:36 +0100 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [BUG] Regression in networking code (SIGSEGV) 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> In-Reply-To: <20090202163806.GA29674@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov , QEMU Developers Gleb Natapov schrieb: > On Sun, Feb 01, 2009 at 09:11:59PM +0100, Stefan Weil wrote: >> Hi, >> >> Up to now, I could not get the crash with i386 guests, but I don't >> think it >> depends on the guest because all guests share the same binary code of >> slirp. >> >> It does depend on the kind and on the amount of network >> data, because it is triggered only by fragmented packets (see stack in >> my first mail). >> Please note that you have to compile without optimization in order to >> see the >> full stack, because ip_reass is normally inlined by the compiler. >> > Can you catch the traffic with tcpdump in a way suitable for tcpreplay > and send it to me (or make it available for download)? > > -- > Gleb. > 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. Regards Stefan