From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 09:59:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9D5416A4AB for ; Sun, 12 Nov 2006 09:59:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1927E43D4C for ; Sun, 12 Nov 2006 09:59:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 73488 invoked from network); 12 Nov 2006 09:52:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 09:52:39 -0000 Message-ID: <4556F086.7050201@freebsd.org> Date: Sun, 12 Nov 2006 10:59:34 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Anish Mistry References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <4555BA65.4020603@gmail.com> <45560FB8.1040607@freebsd.org> <200611112302.23508.amistry@am-productions.biz> In-Reply-To: <200611112302.23508.amistry@am-productions.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 09:59:36 -0000 Anish Mistry wrote: > On Saturday 11 November 2006 13:00, Andre Oppermann wrote: >> Pawel Worach wrote: >>> Andre Oppermann wrote: >>>> I'm looking into the problem. Please try a binary FTP transfer >>>> as well and check if the checksums match. ftpd uses sendfile(2) >>>> as well but w/o headers or trailers and does the send in one >>>> swoop. >>> Oh, didn't think of that, ftpd is ok, transferring a 64MB file >>> does not trash it. Meanwhile a couple of other things where >>> tested, SMP disabled (removed from kernel config), added some >>> printf's which when printing to a serial console moves the offset >>> where the breakage begins to 0x01000000, sometimes. >> I tried to reproduce the problem with lighttpd w/o success. >> >> My guess is that something gets wrong when using non-blocking >> sockets and the http headers. Could you obtain the truss of the >> sendfile(2) calls so I get the input parameters to it? A visual >> inspection of a corruptly transferred text file would be helpful >> too. This should give more hints what happens, like duplicated or >> missing pages, etc. > For me I'm seeing 3 different behaviors. > 1) The file is just truncated after a few KB. > 2) A section of the file is just missing. eg. A small section of the > file in the middle is just gone. > 3) The data is sent before the headers. eg. a portion of the html is > sent, and then you see What webserver are you running? > The following shows 1) and 2). > http://am-productions.biz/docs/no-menu-default.css.bad > http://am-productions.biz/docs/no-menu-default.css -- Andre