On Thu, Jul 21, 2005 at 10:55:22PM +0100, Paul LeoNerd Evans wrote: > I have determined, by the way, a much more precise location for the bug. > I can start a Knoppix image, which can reliably resolve hostnames, and > ping the host machine. I then tried a http-over-telnet, to test TCP. I > connect, send/receive data just fine. The moment I Ctrl+C the telnet, > that's when qemu dies. So I suspect the bug is related to the TCP close > code. I shall investigate further...
Maybe there's some developers around who know the slirp code better than
I do... But I'm finding something truely bizare here..
slirp/tcp_input.c lines 137-139:
for (q = (struct tcpiphdr *)tp->seg_next; q != (struct tcpiphdr *)tp;
q = (struct tcpiphdr *)q->ti_next)
if (SEQ_GT(q->ti_seq, ti->ti_seq))
break;
We're using tp->seg_next and q->ti_next as pointers to an in-memory
struct.
But; tp's type is defined as:
#if SIZEOF_CHAR_P == 4
typedef struct tcpiphdr *tcpiphdrp_32;
#else
typedef u_int32_t tcpiphdrp_32;
#endif
struct tcpcb {
tcpiphdrp_32 seg_next;ยป/* sequencing queue */
tcpiphdrp_32 seg_prev;
...
}
Which I find odd, seeing as therefore we're using a u_int32_t as a
pointer to a struct..? Sounds oddly dangerous.
Similarly, ti_next is really a macro for ti_i.ih_next, which is
similarly typed as uint32_t.
As sizeof(int) == sizeof(void*) on i386 platforms, I'm guessing that's
why the code works there. Seems quite broken here on AMD64 where
sizeof(void*) == 8.
Seems to me an overloaded use of fields to mean ints in some cases, and
pointers in others...
--
Paul "LeoNerd" Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
_______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
