rtorrent and recent snapshots

rtorrent and recent snapshots

[Chris Sutcliffe]

I tried the 20130114 snapshot and I'm having an issue with rtorrent.
Specifically, after the torrents have been running a short while they
all error out with "Storage error: [Could not sync chunk: Permission
denied]".

Backtracking through the snapshots, it happens all the way back to
20121218, between snapshots 20121215 and 20121016 rtorrent stack dumps
on startup.  The 20121016 snapshot seems to behave as expected.

Let me know if there is anything more I can provide to help debug this issue.

Thanks,

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
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

Re: rtorrent and recent snapshots

[Christopher Faylor]

On Wed, Jan 16, 2013 at 07:31:08PM -0500, Chris Sutcliffe wrote:
>I tried the 20130114 snapshot and I'm having an issue with rtorrent.
>Specifically, after the torrents have been running a short while they
>all error out with "Storage error: [Could not sync chunk: Permission
>denied]".
>
>Backtracking through the snapshots, it happens all the way back to
>20121218, between snapshots 20121215 and 20121016 rtorrent stack dumps
>on startup.  The 20121016 snapshot seems to behave as expected.
>
>Let me know if there is anything more I can provide to help debug this issue.

Is there a stackdump file?  If not, I guess if you could make a strace
available for download that could be useful.

cgf

--
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

Re: rtorrent and recent snapshots

[Chris Sutcliffe]

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.

Thank you,

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
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

Re: rtorrent and recent snapshots

[Chris Sutcliffe]

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,

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Christopher Faylor]

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.

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.

cgf

--
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Chris Sutcliffe]

On 17 January 2013 19:35, Christopher Faylor wrote:
> On Thu, Jan 17, 2013 at 04:42:36PM -0500, Chris Sutcliffe wrote:
>>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.

Testing the 20130118 snapshot and so far so good.  I'll stress test it
some more, but so far I've not been able to recreate the issue.

Thanks for the quick response!

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Corinna Vinschen]

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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Christopher Faylor]

On Fri, Jan 18, 2013 at 10:32:05AM +0100, Corinna Vinschen wrote:
>On Jan 17 19:35, Christopher Faylor wrote:
>> 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

That sounds right to me.  EACCES didn't seem like the right translation
here.

>> 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 ;)

Yeah, my compiler setup is great.  Now if I could just use it to compile
my packages, I'd be very happy.  So far it only seems to work right with
Cygwin.  Other stuff, like gdb and binutils are currently problematic.

I saw that you made another change to this function.  Is it possible that
this might actually fix the "rtorrent problem"?

cgf

--
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Corinna Vinschen]

On Jan 18 10:43, Christopher Faylor wrote:
> On Fri, Jan 18, 2013 at 10:32:05AM +0100, Corinna Vinschen wrote:
> >On Jan 17 19:35, Christopher Faylor wrote:
> >> 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
> 
> That sounds right to me.  EACCES didn't seem like the right translation
> here.

Ok, I'll fix that in errno.cc.

> >> 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 ;)
> 
> Yeah, my compiler setup is great.  Now if I could just use it to compile
> my packages, I'd be very happy.  So far it only seems to work right with
> Cygwin.  Other stuff, like gdb and binutils are currently problematic.

Current binutils CVS HEAD doesn't build on Cygwin(*).  The 2.23.1
version should work, though.

> I saw that you made another change to this function.  Is it possible that
> this might actually fix the "rtorrent problem"?

No.  It only adds the MS_SYNC handling.  rtorrent uses MS_ASYNC.
I think there's basically no way around the loop.  I'm just still
wondering if we shouldn't add a cygwait() call to handle signals
during the wait time.


Corinna

(*) http://sourceware.org/ml/binutils/2013-01/msg00303.html

-- 
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Christopher Faylor]

On Fri, Jan 18, 2013 at 05:07:42PM +0100, Corinna Vinschen wrote:
>Current binutils CVS HEAD doesn't build on Cygwin(*).  The 2.23.1
>version should work, though.

I have a number of weird problems building binutils that will take some
time to track down.

cgf

--
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Andrey Repin]

Greetings, Corinna Vinschen!

>> I saw that you made another change to this function.  Is it possible that
>> this might actually fix the "rtorrent problem"?

> No.  It only adds the MS_SYNC handling.  rtorrent uses MS_ASYNC.

That made me think... If rtorrent uses MS_ASYNC, shouldn't *rtorrent* be
prepared for consequences? Instead of you trying to satisfy its
expectations?

> I think there's basically no way around the loop.  I'm just still
> wondering if we shouldn't add a cygwait() call to handle signals
> during the wait time.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 19.01.2013, <00:15>

Sorry for my terrible english...


--
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Christopher Faylor]

On Sat, Jan 19, 2013 at 12:18:39AM +0400, Andrey Repin wrote:
>Greetings, Corinna Vinschen!
>
>>> I saw that you made another change to this function.  Is it possible that
>>> this might actually fix the "rtorrent problem"?
>
>> No.  It only adds the MS_SYNC handling.  rtorrent uses MS_ASYNC.
>
>That made me think... If rtorrent uses MS_ASYNC, shouldn't *rtorrent* be
>prepared for consequences? Instead of you trying to satisfy its
>expectations?

It does seem that way.

cgf

--
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Christopher Faylor]

On Fri, Jan 18, 2013 at 04:10:25PM -0500, Christopher Faylor wrote:
>On Sat, Jan 19, 2013 at 12:18:39AM +0400, Andrey Repin wrote:
>>Greetings, Corinna Vinschen!
>>
>>>> I saw that you made another change to this function.  Is it possible that
>>>> this might actually fix the "rtorrent problem"?
>>
>>> No.  It only adds the MS_SYNC handling.  rtorrent uses MS_ASYNC.
>>
>>That made me think... If rtorrent uses MS_ASYNC, shouldn't *rtorrent* be
>>prepared for consequences? Instead of you trying to satisfy its
>>expectations?
>
>It does seem that way.

Actually, it isn't that clear.  It seems like msync is failing in the
MS_ASYNC case when it shouldn't be, i.e., rtorrent is within its rights
to expect the operation to succeed.

--
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

Re: rtorrent and recent snapshots - apparent problem with msync()

[Corinna Vinschen]

On Jan 18 16:24, Christopher Faylor wrote:
> On Fri, Jan 18, 2013 at 04:10:25PM -0500, Christopher Faylor wrote:
> >On Sat, Jan 19, 2013 at 12:18:39AM +0400, Andrey Repin wrote:
> >>Greetings, Corinna Vinschen!
> >>
> >>>> I saw that you made another change to this function.  Is it possible that
> >>>> this might actually fix the "rtorrent problem"?
> >>
> >>> No.  It only adds the MS_SYNC handling.  rtorrent uses MS_ASYNC.
> >>
> >>That made me think... If rtorrent uses MS_ASYNC, shouldn't *rtorrent* be
> >>prepared for consequences? Instead of you trying to satisfy its
> >>expectations?

Me adding MS_SYNC handling has nothing to do with the original problem.
It was just something I realized being missing in our msync
implementation while looking into the rtorrent behaviour.

Actually, what I was really looking into at this time was...

> >It does seem that way.
> 
> Actually, it isn't that clear.  It seems like msync is failing in the
> MS_ASYNC case when it shouldn't be, i.e., rtorrent is within its rights
> to expect the operation to succeed.

...this:  Under Linux, msync might return with errno set to EBUSY if
"MS_INVALIDATE was specified in flags, and a memory  lock exists for the
specified address range."(*)

This sounds a lot like what rtorrent occurs.  So, what I was looking for
is if rtorrent calls msync with the MS_INVALIDATE flag, but it doesn't.

Right now the msync loop does not handle MS_INVALIDATE specificially,
only after the loop is exited is EBUSY returned now.  OTOH, usually the
kernel is not expected to lock a memory page temporarily for its own
dubious purposes *and* let a user mode function call fail due to that.


Corinna

(*) http://www.kernel.org/doc/man-pages/online/pages/man2/msync.2.html

-- 
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