X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 18 Jan 2013 10:32:05 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Cc: Chris Sutcliffe <ir0nh34d AT gmail DOT com>
Subject: Re: rtorrent and recent snapshots - apparent problem with msync()
Message-ID: <20130118093205.GB11791@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com, Chris Sutcliffe <ir0nh34d AT gmail DOT com>
References: <CAGHJv4fiyojmQGR_d4=Pv1q9dtJogbcfCKBj_LtWyYsLYOFBGQ AT mail DOT gmail DOT com> <20130117062415 DOT GB24529 AT ednor DOT casa DOT cgf DOT cx> <CAGHJv4cTsRD5km3oSmBy2BbWGTvL2mfbU9xRMPbnj2XCLN7HgQ AT mail DOT gmail DOT com> <CAGHJv4cAm+v_VuKXxjdriTN-d-AoQfengNEFY+MqZOAnOsH0-Q AT mail DOT gmail DOT com> <20130118003522 DOT GA1913 AT ednor DOT casa DOT cgf DOT cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20130118003522.GA1913@ednor.casa.cgf.cx>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Jan 17 19:35, Christopher Faylor wrote:
> On Thu, Jan 17, 2013 at 04:42:36PM -0500, Chris Sutcliffe wrote:
> >On 17 January 2013 06:55, Chris Sutcliffe wrote:
> >> On 17 January 2013 01:24, Christopher Faylor wrote:
> >>> Is there a stackdump file?  If not, I guess if you could make a strace
> >>> available for download that could be useful.
> >>
> >> The current snapshots do not produce a stackdump.  I will execute an
> >> strace this evening when I get home and provide it.
> >
> >I've uploaded the strace for this issue here:
> >
> >http://dl.dropbox.com/u/5530441/cygwin/rtorrent.strace
> >
> >Please let me know if there is anything else I can do to help.
> 
> Thanks.  That helped.
> 
> msync() is failing with an EACCESS errno.  That translates to a windows
> error: ERROR_LOCK_VIOLATION.  According to the ancient wisdom of google,
> it is not uncommon for the FlushViewOfFile() function to return with
> this error in some cases.
> 
> I added a retry to the function fhandler_disk_file::msync and tried
> running rtorrent to download a debian iso (which seemed to be what you
> were doing).  I could duplicate your problem before adding the retry but
> I don't see it now.
> 
> The command I was using:
> 
> rtorrent http://cdimage.debian.org/debian-cd/6.0.6/i386/bt-cd/debian-6.0.6-i386-CD-1.iso.torrent
> 
> I'm generating a snapshot now.  Please give it a try when it shows up.
> 
> And, Corinna, please if the change I made to your function is wrong or
> you just don't like my variable names or comments please feel free to
> expunge what I did with extreme prejudice.

Looks good to me.  I'm just wondering.  I have a similar piece of code
in the rename function in syscalls.cc, lines 2342ff.  This loop also
allows signals to break the loop.  Maybe we should do the same here?

I just read the Linux msync man page(*) as well as the MSDN
FlushViewOfFile man page(**).  Looks like this function is missing a
bit of functionality.  Right now msync only calls FlushViewOfFile.
Per MSDN this is equivalent to msync called with the MS_ASYNC flag.
If the MS_SYNC flag is given, the function should also call FlushFileBuffers.
I'll fix that.

Also, Linux msync is allowed to return with EBUSY if "MS_INVALIDATE was
specified in flags, and a memory lock exists for the specified address
range."  That seems to match our situation... except that rtorrent
doesn't use the MS_INVALIDATE flag.  Either way, maybe we should
translate ERROR_LOCK_VIOLATION to EBUSY?

(*)  http://www.kernel.org/doc/man-pages/online/pages/man2/msync.2.html
(**) http://msdn.microsoft.com/en-us/library/windows/desktop/aa366563%28v=vs.85%29.aspx

> I can't explain what in the newer snapshots would cause a difference
> in behavior other than the fact that they were being built with a
> newer compiler and a revamped configure script.

I tried with my gcc 4.5.3 build and I can't reproduce the problem.
Still, it's just calls to OS functions.  There should be no compiler
induced difference in the error values returned from OS functions.
Except your gcc produces faster code than WIndows allows ;)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple