Mail Archives: cygwin/2013/01/18/04:32:55
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
- Raw text -