From owner-freebsd-current  Thu Nov 14 20:25:03 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA10639
          for current-outgoing; Thu, 14 Nov 1996 20:25:03 -0800 (PST)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA10627
          for <current@freebsd.org>; Thu, 14 Nov 1996 20:24:23 -0800 (PST)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id UAA01844; Thu, 14 Nov 1996 20:23:43 -0800 (PST)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
	id sma001842; Thu Nov 14 20:23:32 1996
Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id UAA19805; Thu, 14 Nov 1996 20:23:32 -0800 (PST)
From: Archie Cobbs <archie@whistle.com>
Message-Id: <199611150423.UAA19805@bubba.whistle.com>
Subject: Re: SERIOUS TCP problem in 3.0 and the new compiler
In-Reply-To: <199611142350.RAA08015@Jupiter.Mcs.Net> from Karl Denninger at "Nov 14, 96 05:50:51 pm"
To: karl@Mcs.Net (Karl Denninger)
Date: Thu, 14 Nov 1996 20:23:32 -0800 (PST)
Cc: current@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


> I have uncovered a very serious problem in the new compiler and/or libraries 
> (at least, I think it is) in the -CURRENT branch.
> 
> Unfortunately, I haven't been able to run it down as of yet.
> 
> This is what happens:
> 
> 1)	Open a socket to a server, which forks off a copy of itself after
> 	accepting the socket connection.
> 2)	Send LOTS (thousands) of transactions (a "transaction" is defined
> 	as transmission of one packet of data with a known size and prefix, 
> 	the server end reads it, does something, and responds in some way 
> 	with data).
> 
> At some point a few thousand transactions into the process, you "lose" one
> of the responses.  That is, the process which is doing the serving THINKS it
> wrote a response, but the CLIENT never gets it!
> 
> Since this is a lock-step protocol, and we're relying on TCP to do the
> reliability part of data delivery, and no more than one request can ever be
> outstanding in this protocol, you're screwed.  The process locks up hard.
> 
> If we recompile under gcc 2.6.3, even running with a 3.0 (-current) kernel,
> the problem DOES NOT happen.  If you compile under the current release (as
> of 11/11 at least) it *DOES* -- reliably.

Can you provide some sample code, ie., the smallest piece(s) of code
that reproduce the problem?

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com