Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
Hi Bert, I'll see if I can properly fix this (preferably in both Subversion and Apr), without reverting to just ignoring errors. Did you have any success fixing it yet? Is there already a bug entered in the issue tracker? I'd rate it as blocker priority. -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog
RE: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
> -Original Message-
> From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
> Sent: maandag 17 augustus 2015 08:58
> To: Philip Martin
> Cc: Branko Čibej ; dev@subversion.apache.org
> Subject: Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
> capability" errors
>
> On 14.08.2015 11:21, Philip Martin wrote:
> > Marc Strapetz writes:
> >
> >> It's reproducible with an empty repository on the server (just
> >> initialized with svnadmin) and a local repository which has been
> >> prepared for the initial import:
> >>
> >> C:\temp\svn> svn status -v
> >> 00 ? .
> >> A- ? ? dir
> >> A- ? ? dir\subfile
> >> A- ? ? file
> >>
> >> C:\temp\svn> svn commit -m "initial import"
> >> svn: E140004: Commit failed (details follow):
> >> svn: E140004: Stream doesn't support this capability
> >> svn: E09: Polling for available data on filestream failed: Bad
> >> file descriptor
> >>
> >> On the server, we are running SVN 1.6.17.
> >
> > That's the apr_poll() call in data_available_handler_apr() failing, and
> > E09 could be EBADF. I suppose the file could have been closed, or
> > the file descriptor could have been overwritten. What do you see in the
> > debugger?
>
> Philip, is there any input you are expecting from my side? Because I
> don't have an idea how I should debug this on the server side.
>
> Do you think the problem can be caused by the rather old version SVN
> 1.6.17 on the server? Either way, there must have happened something in
> the SVN 1.9 release as well, breaking this.
The problem is caused by apr not implementing file polling on Windows.
[[
else if (aprset[i].desc_type == APR_POLL_FILE) {
#if !APR_FILES_AS_SOCKETS
return APR_EBADF;
#else
fd = aprset[i].desc.f->filedes;
#endif
}
]]
Before Subversion 1.9 the code around the polling ignored errors and just
checked for success.
I'll see if I can properly fix this (preferably in both Subversion and Apr),
without reverting to just ignoring errors.
Bert
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
On 14.08.2015 11:21, Philip Martin wrote: Marc Strapetz writes: It's reproducible with an empty repository on the server (just initialized with svnadmin) and a local repository which has been prepared for the initial import: C:\temp\svn> svn status -v 00 ? . A- ? ? dir A- ? ? dir\subfile A- ? ? file C:\temp\svn> svn commit -m "initial import" svn: E140004: Commit failed (details follow): svn: E140004: Stream doesn't support this capability svn: E09: Polling for available data on filestream failed: Bad file descriptor On the server, we are running SVN 1.6.17. That's the apr_poll() call in data_available_handler_apr() failing, and E09 could be EBADF. I suppose the file could have been closed, or the file descriptor could have been overwritten. What do you see in the debugger? Philip, is there any input you are expecting from my side? Because I don't have an idea how I should debug this on the server side. Do you think the problem can be caused by the rather old version SVN 1.6.17 on the server? Either way, there must have happened something in the SVN 1.9 release as well, breaking this. -Marc
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
Is *anybody* of the Windows users able to commit using svn+ssh:// and SVN 1.9? -- Thomas On 14.08.2015 00:20, Branko Čibej wrote: On 13.08.2015 13:32, Marc Strapetz wrote: On 27.07.2015 09:21, Branko Čibej wrote: On 27.07.2015 09:17, Marc Strapetz wrote: One of our 1.9 (early-access) users is reporting problems when performing remote commands, for example a copy URL->URL: org.apache.subversion.javahl.ClientException: Stream doesn't support this capability Bad file descriptor svn: Polling for available data on filestream failed: Bad file descriptor at org.apache.subversion.javahl.SVNClient.copy(Native Method) at ... He hasn't encountered such problems with 1.8 versions. AFAIU, he is connecting using SSH. Is this an SSH-related problem? Could it be related to the underlying SSH client? Which platform is this? Can the user reproduce this problem with the command-line svn on the same machine? It's on Windows, in combination with SSH. I'm now able to reproduce this problem myself and it looks like a regression to me: It's reproducible with our own Windows binaries as well as with the WANdisco binaries. It's reproducible with Plink/Pageant as well as with Trilead SSH. The commit works fine with Subversion 1.8. Is there any additional information/debugging I can do on my side? I'd still want to know if the command-line client works. If not, a minimal Java program using JavaHL that demonstrates the problem would be a real help. -- Brane
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
Philip Martin writes: > That's the apr_poll() call in data_available_handler_apr() failing, and > E09 could be EBADF. Perhaps E09 is not EBADF on Windows? Looking on Google I find Error Code 9: The storage control block address is invalid. [ERROR_INVALID_BLOCK (0x9)] I don't know what that means. -- Philip Martin WANdisco
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
Marc Strapetz writes: > It's reproducible with an empty repository on the server (just > initialized with svnadmin) and a local repository which has been > prepared for the initial import: > > C:\temp\svn> svn status -v > 00 ? . > A- ? ? dir > A- ? ? dir\subfile > A- ? ? file > > C:\temp\svn> svn commit -m "initial import" > svn: E140004: Commit failed (details follow): > svn: E140004: Stream doesn't support this capability > svn: E09: Polling for available data on filestream failed: Bad > file descriptor > > On the server, we are running SVN 1.6.17. That's the apr_poll() call in data_available_handler_apr() failing, and E09 could be EBADF. I suppose the file could have been closed, or the file descriptor could have been overwritten. What do you see in the debugger? Breakpoint 2, data_available_handler_apr (baton=0x669500, data_available=0x7fffdccc) at ../src/subversion/libsvn_subr/stream.c:955 955 status = apr_poll(&pfd, 1, &n, 0); (gdb) p pfd.desc.f[0].filedes $6 = 6 On Linux I can check that 6 a valid file descriptor for this process: $ ls -l /proc/28574/fd/6 lr-x-- 1 pm pm 64 Aug 14 10:18 /proc/28574/fd/6 -> pipe:[612259] -- Philip Martin WANdisco
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
On 14.08.2015 00:20, Branko Čibej wrote: On 13.08.2015 13:32, Marc Strapetz wrote: On 27.07.2015 09:21, Branko Čibej wrote: On 27.07.2015 09:17, Marc Strapetz wrote: One of our 1.9 (early-access) users is reporting problems when performing remote commands, for example a copy URL->URL: org.apache.subversion.javahl.ClientException: Stream doesn't support this capability Bad file descriptor svn: Polling for available data on filestream failed: Bad file descriptor at org.apache.subversion.javahl.SVNClient.copy(Native Method) at ... He hasn't encountered such problems with 1.8 versions. AFAIU, he is connecting using SSH. Is this an SSH-related problem? Could it be related to the underlying SSH client? Which platform is this? Can the user reproduce this problem with the command-line svn on the same machine? It's on Windows, in combination with SSH. I'm now able to reproduce this problem myself and it looks like a regression to me: It's reproducible with our own Windows binaries as well as with the WANdisco binaries. It's reproducible with Plink/Pageant as well as with Trilead SSH. The commit works fine with Subversion 1.8. Is there any additional information/debugging I can do on my side? I'd still want to know if the command-line client works. If not, a minimal Java program using JavaHL that demonstrates the problem would be a real help. No, the command-line client does not work: neither the binaries we are building nor WANdisco's binaries. It's reproducible with an empty repository on the server (just initialized with svnadmin) and a local repository which has been prepared for the initial import: C:\temp\svn> svn status -v 00 ? . A- ? ? dir A- ? ? dir\subfile A- ? ? file C:\temp\svn> svn commit -m "initial import" svn: E140004: Commit failed (details follow): svn: E140004: Stream doesn't support this capability svn: E09: Polling for available data on filestream failed: Bad file descriptor On the server, we are running SVN 1.6.17. -Marc
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
On 14.08.2015 00:20, Branko Čibej wrote: On 13.08.2015 13:32, Marc Strapetz wrote: On 27.07.2015 09:21, Branko Čibej wrote: On 27.07.2015 09:17, Marc Strapetz wrote: One of our 1.9 (early-access) users is reporting problems when performing remote commands, for example a copy URL->URL: org.apache.subversion.javahl.ClientException: Stream doesn't support this capability Bad file descriptor svn: Polling for available data on filestream failed: Bad file descriptor at org.apache.subversion.javahl.SVNClient.copy(Native Method) at ... He hasn't encountered such problems with 1.8 versions. AFAIU, he is connecting using SSH. Is this an SSH-related problem? Could it be related to the underlying SSH client? Which platform is this? Can the user reproduce this problem with the command-line svn on the same machine? It's on Windows, in combination with SSH. I'm now able to reproduce this problem myself and it looks like a regression to me: It's reproducible with our own Windows binaries as well as with the WANdisco binaries. It's reproducible with Plink/Pageant as well as with Trilead SSH. The commit works fine with Subversion 1.8. Is there any additional information/debugging I can do on my side? I'd still want to know if the command-line client works. No, it doesn't. That's what Marc meant with "It's reproducible with our own Windows binaries as well as with the WANdisco binaries." The problem is reproducible independent of SmartSVN. -- Thomas
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
On 13.08.2015 13:32, Marc Strapetz wrote: > On 27.07.2015 09:21, Branko Čibej wrote: >> On 27.07.2015 09:17, Marc Strapetz wrote: >>> One of our 1.9 (early-access) users is reporting problems when >>> performing remote commands, for example a copy URL->URL: >>> >>> org.apache.subversion.javahl.ClientException: Stream doesn't support >>> this capability >>> Bad file descriptor >>> svn: Polling for available data on filestream failed: Bad file >>> descriptor >>> at org.apache.subversion.javahl.SVNClient.copy(Native Method) >>> at ... >>> >>> He hasn't encountered such problems with 1.8 versions. >>> >>> AFAIU, he is connecting using SSH. Is this an SSH-related problem? >>> Could it be related to the underlying SSH client? >> >> Which platform is this? Can the user reproduce this problem with the >> command-line svn on the same machine? > > It's on Windows, in combination with SSH. I'm now able to reproduce > this problem myself and it looks like a regression to me: > > It's reproducible with our own Windows binaries as well as with the > WANdisco binaries. It's reproducible with Plink/Pageant as well as > with Trilead SSH. The commit works fine with Subversion 1.8. > > Is there any additional information/debugging I can do on my side? I'd still want to know if the command-line client works. If not, a minimal Java program using JavaHL that demonstrates the problem would be a real help. -- Brane
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
On 27.07.2015 09:21, Branko Čibej wrote: On 27.07.2015 09:17, Marc Strapetz wrote: One of our 1.9 (early-access) users is reporting problems when performing remote commands, for example a copy URL->URL: org.apache.subversion.javahl.ClientException: Stream doesn't support this capability Bad file descriptor svn: Polling for available data on filestream failed: Bad file descriptor at org.apache.subversion.javahl.SVNClient.copy(Native Method) at ... He hasn't encountered such problems with 1.8 versions. AFAIU, he is connecting using SSH. Is this an SSH-related problem? Could it be related to the underlying SSH client? Which platform is this? Can the user reproduce this problem with the command-line svn on the same machine? It's on Windows, in combination with SSH. I'm now able to reproduce this problem myself and it looks like a regression to me: It's reproducible with our own Windows binaries as well as with the WANdisco binaries. It's reproducible with Plink/Pageant as well as with Trilead SSH. The commit works fine with Subversion 1.8. Is there any additional information/debugging I can do on my side? -Marc
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
On 27.07.2015 10:50, Marc Strapetz wrote: > On 27.07.2015 09:21, Branko Čibej wrote: >> On 27.07.2015 09:17, Marc Strapetz wrote: >>> One of our 1.9 (early-access) users is reporting problems when >>> performing remote commands, for example a copy URL->URL: >>> >>> org.apache.subversion.javahl.ClientException: Stream doesn't support >>> this capability >>> Bad file descriptor >>> svn: Polling for available data on filestream failed: Bad file >>> descriptor >>> at org.apache.subversion.javahl.SVNClient.copy(Native Method) >>> at ... >>> >>> He hasn't encountered such problems with 1.8 versions. >>> >>> AFAIU, he is connecting using SSH. Is this an SSH-related problem? >>> Could it be related to the underlying SSH client? >> >> Which platform is this? > > It's Windows 8.1. > > > Can the user reproduce this problem with the >> command-line svn on the same machine? > > I'm going to ask him and would point him to the binaries we are > building unless this could be a problem of the build process -- in > this case, which binaries do you recommend on Windows? We don't recomment any. :) I'm not aware of any recent 1.9.0-rc3 prerelease binaries for Windows. -- Brane
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
On 27.07.2015 09:21, Branko Čibej wrote: On 27.07.2015 09:17, Marc Strapetz wrote: One of our 1.9 (early-access) users is reporting problems when performing remote commands, for example a copy URL->URL: org.apache.subversion.javahl.ClientException: Stream doesn't support this capability Bad file descriptor svn: Polling for available data on filestream failed: Bad file descriptor at org.apache.subversion.javahl.SVNClient.copy(Native Method) at ... He hasn't encountered such problems with 1.8 versions. AFAIU, he is connecting using SSH. Is this an SSH-related problem? Could it be related to the underlying SSH client? Which platform is this? It's Windows 8.1. > Can the user reproduce this problem with the command-line svn on the same machine? I'm going to ask him and would point him to the binaries we are building unless this could be a problem of the build process -- in this case, which binaries do you recommend on Windows? -Marc
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
On 27.07.2015 09:17, Marc Strapetz wrote: > One of our 1.9 (early-access) users is reporting problems when > performing remote commands, for example a copy URL->URL: > > org.apache.subversion.javahl.ClientException: Stream doesn't support > this capability > Bad file descriptor > svn: Polling for available data on filestream failed: Bad file descriptor > at org.apache.subversion.javahl.SVNClient.copy(Native Method) > at ... > > He hasn't encountered such problems with 1.8 versions. > > AFAIU, he is connecting using SSH. Is this an SSH-related problem? > Could it be related to the underlying SSH client? Which platform is this? Can the user reproduce this problem with the command-line svn on the same machine? -- Brane
