From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DvzzG-0002LJ-Sg for qemu-devel@nongnu.org; Fri, 22 Jul 2005 12:02:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DvzzD-0002JV-6r for qemu-devel@nongnu.org; Fri, 22 Jul 2005 12:02:56 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DvzzC-0002EM-Fp for qemu-devel@nongnu.org; Fri, 22 Jul 2005 12:02:54 -0400 Received: from [217.147.80.44] (helo=cel.leo) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dvzy0-0005cf-CZ for qemu-devel@nongnu.org; Fri, 22 Jul 2005 12:01:40 -0400 Date: Fri, 22 Jul 2005 16:51:25 +0100 From: Paul LeoNerd Evans Message-ID: <20050722155125.GC3558@cel.leo> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy" Content-Disposition: inline Subject: [Qemu-devel] Anyone familiar with the slirp code? Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all again, I'm looking over the slirp code, trying to work out the exact nature of this AMD64 bug. So far I've determined that some 32bit integer fields are being used to store struct pointers in - very bad on AMD64 because pointers are 64 bit. From what I can tell, I can't see how the code would ever work on any 64 bit machine - can anyone here confirm if this is indeed the case? What I observe is an immediate segfault of Qemu itself when the guest OS closes a TCP socket. What is further confusing me is that I can't find parts of code that write many of the values; only bits that read them. For example, a search for anything on the ti_next field gives only the following hits: =2E/slirp/tcp_input.c:137: q =3D (struct tcpiphdr *)q->ti_next) =2E/slirp/tcp_input.c:170: q =3D (struct tcpiphdr *)(q->ti_n= ext); =2E/slirp/tcp_input.c:190: q =3D (struct tcpiphdr *)q->ti_ne= xt; =2E/slirp/tcp_input.c:218: ti =3D (struct tcpiphdr *)ti->ti_= next; =2E/slirp/tcp_input.c:305: ti->ti_next =3D ti->ti_prev =3D 0; =2E/slirp/tcp_subr.c:87: n->ti_next =3D n->ti_prev =3D 0; =2E/slirp/tcp_subr.c:170: ti->ti_next =3D ti->ti_prev =3D 0; =2E/slirp/tcp_subr.c:288: t =3D (struct tcpiphdr *)t->ti_next; =2E/slirp/tcpip.h:47:#define ti_next ti_i.ih_next There are no hits for ih_next directly on its own, other than this macro define, and some unrelated hits in the udp.c file. I can't see anywhere where these values are initialised, which leads me to think there must be something odd going on with different types of struct, and pointers to them specifically cast about between the types, and members accessed this way. It seems to me quite a fragile way to work.... Is anyone here familiar with the way the code is intended to run..? I would like to get to the bottom of the issue, and fix it in a proper robust way... --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC4RX9vcPg11V/1hgRAp8HAJ4uu98c/CKtN44LWYcInqy7WfN1EACfTO6b Du4qSoMgrLKiJveXTJdqkdk= =JMt7 -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy--