From owner-freebsd-net@FreeBSD.ORG Sun Jun 29 11:58:27 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03492106567A; Sun, 29 Jun 2008 11:58:27 +0000 (UTC) (envelope-from ali@transip.nl) Received: from relay0.transip.nl (relay0.transip.nl [80.69.67.21]) by mx1.freebsd.org (Postfix) with ESMTP id BCAB48FC0C; Sun, 29 Jun 2008 11:58:26 +0000 (UTC) (envelope-from ali@transip.nl) Received: from [192.168.0.3] (ip86-50-212-87.adsl2.static.versatel.nl [87.212.50.86]) by relay0.transip.nl (Postfix) with ESMTP id 1D70310310A; Sun, 29 Jun 2008 13:58:24 +0200 (CEST) Message-ID: <486778CE.4000103@transip.nl> Date: Sun, 29 Jun 2008 13:58:06 +0200 From: Ali Niknam Organization: Transip BV User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Robert Watson References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> <20080626081831.V96707@fledge.watson.org> <20080627090939.M78484@fledge.watson.org> <20080629073519.D10134@fledge.watson.org> In-Reply-To: <20080629073519.D10134@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Probably not a kernel bug (was: Re: FreeBSD 7.0: sockets stuck in CLOSED state...) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2008 11:58:27 -0000 Hi Guys, > Another public follow-up: Ali has been sending me debugging information > privately due to the inclusion of application source code and IP > addresses. Tracing of the application suggests that there is an > application concurrency bug leading to one socket to be closed twice and > another socket to be left open. The bug might be triggering in 7.x but > not earlier releases because of the change to libthr, which can lead to > more parallelism/asynchrony in the application. > After more testing I can with almost absolute certainty conclude that it is indeed an application bug. Reasons that it did not manifest itself earlier most probably are due to the much increased performance of BSD 7, making a certain race condition likely where it once was improbable. I want to thank all who've helped track this issue down! Kind Regards, Ali