Re: svn commit: r1701633 - /subversion/trunk/subversion/libsvn_subr/stream.c

[Ivan Zhakov]

On 7 September 2015 at 18:06,   wrote:
> Author: kotkov
> Date: Mon Sep  7 15:06:57 2015
> New Revision: 1701633
>
> URL: http://svn.apache.org/r1701633
> Log:
> Fix svn_stream_for_stdin() and related functions for STDOUT and STDERR
> that were returning streams with mark() and seek() capabilities.
>
> STDIN, STDOUT and STDERR don't provide general support for positioning
> requests.  This behavior is implementation-specific and depends on what's
> passed as the corresponding handle.  For example, on Linux, apr_file_seek()
> that calls lseek() internally fails with ESPIPE [1] when the descriptor is
> associated with a terminal device.  As we cannot safely advertise mark()
> and seek() support for these streams, don't do that.
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html
>
> * subversion/libsvn_subr/stream.c
>   (svn_stream_for_stdin, svn_stream_for_stdout, svn_stream_for_stderr):
>Don't install mark and seek handlers.
>
It may be worth to introduce local helper like
'make_stream_from_apr_file(svn_boolean_t supports_seek)' and use it in
svn_stream_from_apr_file2() and svn_stream_for_stdin() instead of
clearing mark/seek handlers after calling svn_stream_from_apr_file2().

Another problem that currently svn_stream_t for stdin/stderr/stdout
pretends to support native svn_stream_skip(), while I'm not sure that
all platforms support seek for stdin.

-- 
Ivan Zhakov

Re: Access denied error on checkout-commit after updating to 1.9.X

[Ivan Zhakov]

On 7 September 2015 at 19:45, Ivan Zhakov  wrote:
> [Moving to dev@s.a.o]
>
> On 4 September 2015 at 18:15, Daniele Pedroni
>  wrote:
>> After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN
>> as well as command line throw the following error after trying to checkout
>> or commit a Working Directory on a network share:
>>
>> Commit failed (details follow):
>> Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to
>>
>> 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base':
>>  Access is denied.
>>
>> (full discussion on TSVN mailing list here:
>> https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U )
>>
>> It seems to be a Subversion issue, not a TortoiseSVN one, since command line
>> acts exactly the same as TSVN: everything fine with local paths, issues with
>> network drives. Sometimes, trying more and more, the checkout/commit
>> succeeds also on network share, but it is a random occurrence.
>>
>> Any clue? As you can see in the suggested link, it seems that everyone who
>> works on network drive has the same problem: something has been changed or
>> broken in 1.9.X release about it? I didn’t find anything about it.
>>
> Bert and I were able to reproduce this issue with help from Daniele
> and Marco. In short: Subversion 1.9.x doesn't work with working copies
> stored on SMBv1 network shares (i.e. hosted on Windows XP/Windows
> Server 2003 or Windows Server 2008 with SMBv2 disabled). It is not
> related to background antivirus/indexers. So the bug affects many
> users.
>
> While r1701298 fix still makes sense to workaround background
> antivirus/indexers it doesn't help to fix Access Denied errors on
> SMBv1 network shares.
>
> In nutshell problem is that SetFileInformationByHandle() API cannot be
> called more than once if first call failed for any reason for SMBv1
> shares. We retry SetFileInformationByHandle() call if destination
> directory doesn't exist or if we rename over read-only file. It works
> fine for local directories or SMBv2 shares, but doesn't work for SMBv1
> network shares. SetFileInformationByHandle() returns
> ERROR_ACCESS_DENIED without even sending request to SMB server.
>
> We developed patch that converts all ERROR_ACCESS_DENIED errors from
> SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and
> fallbacks to normal close + rename() (see attached file), but I'm not
> sure it's the best solution and going to investigate this problem
> tomorrow.
>
I didn't find better solution and committed this patch in r1701736.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

JavaHL: Hard crash in libsvn_subr-1.dll

[Thomas Singer]

We've got the attached bug report where libsvn_subr-1.dll crashes. 
Unfortunately, I have no idea how to reproduce.


--
Best regards,
Thomas Singer
=
syntevo GmbH
http://www.syntevo.com
http://www.syntevo.com/blog
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x5edc4c20, pid=13340, tid=6728
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) Client VM (24.65-b04 mixed mode windows-x86 )
# Problematic frame:
# C  [libsvn_subr-1.dll+0xc4c20]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x3e026400):  JavaThread "WorkerThread-3" [_thread_in_native, id=6728, stack(0x3cd5,0x3cda)]

siginfo: ExceptionCode=0xc005, reading address 0x

Registers:
EAX=0x, EBX=0x, ECX=0x, EDX=0x0001
ESP=0x3cd9d6d0, EBP=0x3cd9d6d0, ESI=0x3e193138, EDI=0x
EIP=0x5edc4c20, EFLAGS=0x00010202

Top of Stack: (sp=0x3cd9d6d0)
0x3cd9d6d0:   3cd9d6f0 5f4ee618  3e18525c
0x3cd9d6e0:   3e1850c0 3df70180 3e185100 3e18525c
0x3cd9d6f0:   3cd9d73c 5f4f18b0 3e185108 3e193138
0x3cd9d700:   3e1850c0 3df3e1c8 3df414c0 3df4c158
0x3cd9d710:   01e79fa0 3e185108  3e185100
0x3cd9d720:    2008 3e193144 3cd9d74c
0x3cd9d730:   3df70180  3e18b0d8 3cd9d768
0x3cd9d740:   70646fa8 3df3e0a8 3e193138  

Instructions: (pc=0x5edc4c20)
0x5edc4c00:   8d 04 31 5e 5d c3 cc cc cc cc cc cc cc cc cc cc
0x5edc4c10:   55 8b ec 8b 45 08 8d 50 01 8d a4 24 00 00 00 00
0x5edc4c20:   8a 08 40 84 c9 75 f9 53 56 2b c2 57 8b 7d 0c 8b
0x5edc4c30:   f0 8b c7 8d 50 01 8a 08 40 84 c9 75 f9 2b c2 8b 


Register to memory mapping:

EAX=0x is an unknown value
EBX=0x is an unknown value
ECX=0x is an unknown value
EDX=0x0001 is an unknown value
ESP=0x3cd9d6d0 is pointing into the stack for thread: 0x3e026400
EBP=0x3cd9d6d0 is pointing into the stack for thread: 0x3e026400
ESI=0x3e193138 is an unknown value
EDI=0x is an unknown value


Stack: [0x3cd5,0x3cda],  sp=0x3cd9d6d0,  free space=309k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libsvn_subr-1.dll+0xc4c20]
C  [libsvn_wc-1.dll+0x4e618]
C  [libsvn_wc-1.dll+0x518b0]
C  [libsvn_delta-1.dll+0x6fa8]
C  [libsvn_ra-1.dll+0x4ddd0]
C  [libsvn_ra-1.dll+0x4fbdd]
C  [libsvn_ra-1.dll+0x3e583]
C  [libsvn_ra-1.dll+0x123da]
C  [libsvn_ra-1.dll+0x128f2]
C  [libsvn_ra-1.dll+0x13ee6]
C  [libsvn_ra-1.dll+0xe030]
C  [libsvn_ra-1.dll+0xdacd]
C  [libsvn_ra-1.dll+0xf3ab]
C  [libsvn_ra-1.dll+0x3f427]
C  [libsvn_ra-1.dll+0x4e4d2]
C  [libsvn_ra-1.dll+0x4a610]
C  [libsvn_ra-1.dll+0x4a6bd]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.apache.subversion.javahl.SVNClient.update(Ljava/util/Set;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;)[J+0
j  smartsvn.SZ.a(Lorg/apache/subversion/javahl/ISVNClient;Lsmartsvn/axi;)Ljava/lang/Object;+29
j  smartsvn.Sx.a(Lsmartsvn/Tz;Lsmartsvn/axi;)Ljava/lang/Object;+117
j  smartsvn.Sx.a(Lsmartsvn/Tz;)Ljava/lang/Object;+31
j  smartsvn.Sx.a(Ljava/util/Set;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;)[J+24
j  smartsvn.Sx.a(Ljava/util/Set;Lorg/apache/subversion/javahl/types/Revision;Lsmartsvn/te;)[J+46
j  smartsvn.arh.a(Lsmartsvn/axk;Lsmartsvn/aAa;Lsmartsvn/avk;Lsmartsvn/ua;Lsmartsvn/tW;)Lsmartsvn/pO;+534
j  smartsvn.TP.a(Lsmartsvn/axk;Lsmartsvn/ua;Lsmartsvn/tW;)Lsmartsvn/pO;+159
j  smartsvn.aFY.a(Lsmartsvn/ua;Lsmartsvn/tW;)Lsmartsvn/pO;+70
j  smartsvn.aFT.a(Lsmartsvn/ua;Lsmartsvn/tW;)Lsmartsvn/pO;+62
j  smartsvn.qv.run()V+14
j  smartsvn.aFS.run()V+34
j  smartsvn.qb.run()V+81
v  ~StubRoutines::call_stub

---  P R O C E S S  ---

Java Threads: ( => current thread )
  0x3e120400 JavaThread "QThreadPoolThread-4" daemon [_thread_blocked, id=13008, stack(0x41ec,0x41f1)]
  0x3e11f800 JavaThread "QThreadPoolThread-3" daemon [_thread_blocked, id=11568, stack(0x41d6,0x41db)]
  0x3e11f000 JavaThread "QThreadPoolThread-2" daemon [_thread_blocked, id=10248, stack(0x4084,0x4089)]
  0x3e103c00 JavaThread "Transaction-Refresher (srvptsvn--svn-rd)-5" daemon [_thread_blocked, id=15620, stack(0x404f,0x4054)]
  0x3e0ab800 JavaThread "QThreadPoolThread-1" daemon [_thread_blocked, id=9172, stack(0x401d,0x4022)]
  0x3e03d400 JavaThread "Transaction-4" [_thread_blocked, id=8736, stack(0x3d42,0x3d47)]
=>0x3e026400 JavaThread "WorkerThread-3" [_thread_in_native, id=6728, stack(0x3cd5,0x3cda)]
  

Re: svn commit: r1701633 - /subversion/trunk/subversion/libsvn_subr/stream.c

[Ivan Zhakov]

On 8 September 2015 at 14:10, Evgeny Kotkov  wrote:
> Ivan Zhakov  writes:
>
>> It may be worth to introduce local helper like
>> 'make_stream_from_apr_file(svn_boolean_t supports_seek)' and use it in
>> svn_stream_from_apr_file2() and svn_stream_for_stdin() instead of
>> clearing mark/seek handlers after calling svn_stream_from_apr_file2().
>
> Sounds good.
>
>> Another problem that currently svn_stream_t for stdin/stderr/stdout
>> pretends to support native svn_stream_skip(), while I'm not sure that
>> all platforms support seek for stdin.
>
> Indeed, I missed that default skip_handler_apr() performs a seek that could
> be unavailable or behave surprisingly when used with a handle like STDIN.
> So, the fix is partial.
>
> What do you think about the attached patch?
>
Looks good for me.

> As of other callbacks, I found out that data_available_handler_apr() calls
> PeekNamedPipe() on Windows, and if the STDIN handle is a tty, this call
> errors out with ERROR_INCORRECT_FUNCTION.  We currently wrap all errors
> originating from PeekNamedPipe() into SVN_ERR_STREAM_NOT_SUPPORTED, so,
> technically, this behavior follows the contract.  Still, I am thinking
> that this is something we could improve separately.
>
Agree that this can be improved separately.

-- 
Ivan Zhakov

Re: svn commit: r1701633 - /subversion/trunk/subversion/libsvn_subr/stream.c

[Stefan Fuhrmann]

On Tue, Sep 8, 2015 at 11:21 AM, Ivan Zhakov  wrote:

> On 7 September 2015 at 18:06,   wrote:
> > Author: kotkov
> > Date: Mon Sep  7 15:06:57 2015
> > New Revision: 1701633
> >
> > URL: http://svn.apache.org/r1701633
> > Log:
> > Fix svn_stream_for_stdin() and related functions for STDOUT and STDERR
> > that were returning streams with mark() and seek() capabilities.
> >
> > STDIN, STDOUT and STDERR don't provide general support for positioning
> > requests.  This behavior is implementation-specific and depends on what's
> > passed as the corresponding handle.  For example, on Linux,
> apr_file_seek()
> > that calls lseek() internally fails with ESPIPE [1] when the descriptor
> is
> > associated with a terminal device.  As we cannot safely advertise mark()
> > and seek() support for these streams, don't do that.
>

Good find!


> > [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html
> >
> > * subversion/libsvn_subr/stream.c
> >   (svn_stream_for_stdin, svn_stream_for_stdout, svn_stream_for_stderr):
> >Don't install mark and seek handlers.
> >
> It may be worth to introduce local helper like
> 'make_stream_from_apr_file(svn_boolean_t supports_seek)' and use it in
> svn_stream_from_apr_file2() and svn_stream_for_stdin() instead of
> clearing mark/seek handlers after calling svn_stream_from_apr_file2().
>
> Another problem that currently svn_stream_t for stdin/stderr/stdout
> pretends to support native svn_stream_skip(), while I'm not sure that
> all platforms support seek for stdin.
>

One more thing we could do is not adding mark & seek
on stream based on write-only files. I haven't tried but
that's something we should be able to do generically in
svn_stream_from_apr_file already.

-- Stefan^2.

Re: Announcing MaxSVN

[Ivan Zhakov]

On 7 September 2015 at 18:47, Stefan  wrote:
> Hi,
>
> I'm pleased to announce the availability of a new distribution of SVN
> called: "MaxSVN".
> In contrast to other SVN distributions this one is a bit different since it
> aims towards being used primarily to support SVN development rather than
> being used in production environments.
>
> Its primary purpose is to test and identify issues of SVN against the latest
> build tools and dependencies on Windows.
>
> It can however also be useful in other situations like if you wanna check
> whether a current development branch solved a particular issue or to check
> out the new features in an upcoming SVN release before it becomes available
> as part of a final release.
>
> Please note once more that I strongly suggest against using MaxSVN in your
> daily productive use. Please stick with one of the already available Windows
> distributions. A list of these can be found on the MaxSVN webpage:
> http://www.luke1410.de/typo3/index.php?id=97
>
> Also understand that MaxSVN is a product distributed, maintained and created
> by myself and is not directly associated with the Apache Subversion project.
>
> The latest current available builds are:
> - 1.7.22.2 (current latest 1.7 released version)
> - 1.8.14.2 (current latest 1.8 released version)
> - 1.8.15.1 (current 1.8 preview version)
> - 1.9.1.2 (current latest 1.9 released version)
> - 1.9.2.1 (current 1.9 preview version)
> - 1.10.0.2 (current 1.10 preview version)
>
> Feel free to send any feedback directly to me by mail or use the bugtracker
> at http://www.luke1410.de:8090/browse/MAXSVN to add bugreports/feature
> requests.
>
May I suggest to rename branch and trunk builds version to something
like 1.9.x-dev-r and 1.10.x-dev-rXXX? Never replace 'x' with the
current version patch version. I.e. '1.9.x-dev-r1701757'.

Because versions like 1.9.2.1 may confuse users. It's very hard to
find difference between 1.9.1.2 and 1.9.2.1 to distinguish official
releases from development builds.

Thanks!

-- 
Ivan Zhakov

Re: svn commit: r1700799 - in /subversion/trunk/subversion: include/svn_io.h libsvn_subr/stream.c svnadmin/svnadmin.c svnfsfs/load-index-cmd.c tests/libsvn_subr/stream-test.c

[Stefan Fuhrmann]

On Mon, Sep 7, 2015 at 6:38 PM, Evgeny Kotkov 
wrote:

> Stefan Fuhrmann  writes:
>
> > That is indeed a good idea, so I tried it in various ways:
> >
> > Index: subversion/libsvn_subr/stream.c
> > ===
> > --- subversion/libsvn_subr/stream.c(revision 1701330)
> > +++ subversion/libsvn_subr/stream.c(working copy)
> > @@ -1826,10 +1826,20 @@ svn_stream_for_stdin(svn_stream_t **in,
> apr_pool_t
> >apr_status_t apr_err;
> >
> >apr_err = apr_file_open_stdin(_file, pool);
> > +
> > +/* Alternatively to the above: tell APR to create a buffered file
> > +  apr_err = apr_file_open_flags_stdin(_file, APR_BUFFERED, pool);
> > +*/
> >if (apr_err)
> >  return svn_error_wrap_apr(apr_err, "Can't open stdin");
>
> The original commit begins using svn_stream_wrap_buffered_read() during
> svnadmin load-revprops and svnfsfs load-index.  This patch, however, does
> something entirely different and adds buffering to *every* stdin.
>

Sorry for the confusion. I did not intend to actually change the
implementation of svn_stream_for_stdin this way but simply
tried to demonstrate a problem with APR buffer reads for
"streamy" file handles.

I am not sure why would we want to do this, but there certainly is a reason
> against a change like this — buffering can't be used when something
> interactive
> happens using stdin, e.g., with svnserve.
>

It is certainly useful to make buffering available as an option
(like you suggested below) instead of wrapping the stream
locally or wrapping it unconditionally. Currently, I'm not 100%
sure whether always wrapping stdin would be safe but I think
it is at least for correct usage:

A read to the wrapper will translate to at most 1 read at the
APR layer, so it will never request more data from stdin than
stdin can deliver at the moment. Exception: Single byte reads
may block scenarios just as and because they do at the APR
level.

So, whatever logic a stream API user applies to determine
that some interaction is required before new data can arrive
in stdin, that logic applies 1:1 with and without the wrapper.

So, why can't we enable buffering for these subcommands (perhaps including
> svnadmin load), leave everything else as is and avoid the necessity of
> having
> and maintaining the custom buffered stream adapter?
>

The underlying problem is still present: If stdin can't deliver
data fast enough (e.g. some hick-up / long latency on the
producer side of a dump | load), a buffered APR file will
error out while a non-buffered one will simply wait & retry.

However, I have yet to try and provoke the error specifically
for the dump | load scenario.

We could introduce svn_stream_for_stdin2(..., svn_boolean_t buffered, ...),
> and then the required change for svnadmin load-revprops would look as below
> (changes for other subcommands would look almost exactly the same):
>

Regardless of the buffering method used, +1 on adding
a rev'ed API.

-- Stefan^2.


>
> [[[
> Index: subversion/libsvn_subr/stream.c
> ===
> --- subversion/libsvn_subr/stream.c (revision 1701648)
> +++ subversion/libsvn_subr/stream.c (working copy)
> @@ -1820,12 +1820,20 @@ svn_stream_wrap_buffered_read(svn_stream_t *inner,
>
>
>  svn_error_t *
> -svn_stream_for_stdin(svn_stream_t **in, apr_pool_t *pool)
> +svn_stream_for_stdin2(svn_stream_t **in,
> +  svn_boolean_t buffered,
> +  apr_pool_t *pool)
>  {
>apr_file_t *stdin_file;
>apr_status_t apr_err;
> +  apr_int32_t flags;
>
> -  apr_err = apr_file_open_stdin(_file, pool);
> +  if (buffered)
> +flags = APR_BUFFERED;
> +  else
> +flags = 0;
> +
> +  apr_err = apr_file_open_flags_stdin(_file, flags, pool);
>if (apr_err)
>  return svn_error_wrap_apr(apr_err, "Can't open stdin");
>
> Index: subversion/svnadmin/svnadmin.c
> ===
> --- subversion/svnadmin/svnadmin.c  (revision 1701648)
> +++ subversion/svnadmin/svnadmin.c  (working copy)
> @@ -1547,8 +1547,7 @@ subcommand_load_revprops(apr_getopt_t *os, void *b
>SVN_ERR(open_repos(, opt_state->repository_path, pool));
>
>/* Read the stream from STDIN.  Users can redirect a file. */
> -  SVN_ERR(svn_stream_for_stdin(_stream, pool));
> -  stdin_stream = svn_stream_wrap_buffered_read(stdin_stream, pool);
> +  SVN_ERR(svn_stream_for_stdin2(_stream, TRUE, pool));
>
>/* Progress feedback goes to STDOUT, unless they asked to suppress it.
> */
>if (! opt_state->quiet)
>
> ]]]
>
>
> Regards,
> Evgeny Kotkov
>

Re: svn commit: r1701633 - /subversion/trunk/subversion/libsvn_subr/stream.c

[Evgeny Kotkov]

Ivan Zhakov  writes:

> It may be worth to introduce local helper like
> 'make_stream_from_apr_file(svn_boolean_t supports_seek)' and use it in
> svn_stream_from_apr_file2() and svn_stream_for_stdin() instead of
> clearing mark/seek handlers after calling svn_stream_from_apr_file2().

Sounds good.

> Another problem that currently svn_stream_t for stdin/stderr/stdout
> pretends to support native svn_stream_skip(), while I'm not sure that
> all platforms support seek for stdin.

Indeed, I missed that default skip_handler_apr() performs a seek that could
be unavailable or behave surprisingly when used with a handle like STDIN.
So, the fix is partial.

What do you think about the attached patch?

As of other callbacks, I found out that data_available_handler_apr() calls
PeekNamedPipe() on Windows, and if the STDIN handle is a tty, this call
errors out with ERROR_INCORRECT_FUNCTION.  We currently wrap all errors
originating from PeekNamedPipe() into SVN_ERR_STREAM_NOT_SUPPORTED, so,
technically, this behavior follows the contract.  Still, I am thinking
that this is something we could improve separately.


Regards,
Evgeny Kotkov
Index: subversion/libsvn_subr/stream.c
===
--- subversion/libsvn_subr/stream.c (revision 1701648)
+++ subversion/libsvn_subr/stream.c (working copy)
@@ -1055,10 +1055,12 @@ svn_stream_open_unique(svn_stream_t **stream,
 }
 
 
-svn_stream_t *
-svn_stream_from_aprfile2(apr_file_t *file,
- svn_boolean_t disown,
- apr_pool_t *pool)
+/* Helper function that creates a stream from an APR file. */
+static svn_stream_t *
+make_stream_from_apr_file(apr_file_t *file,
+  svn_boolean_t disown,
+  svn_boolean_t supports_seek,
+  apr_pool_t *pool)
 {
   struct baton_apr *baton;
   svn_stream_t *stream;
@@ -1072,9 +1074,14 @@ svn_stream_open_unique(svn_stream_t **stream,
   stream = svn_stream_create(baton, pool);
   svn_stream_set_read2(stream, read_handler_apr, read_full_handler_apr);
   svn_stream_set_write(stream, write_handler_apr);
-  svn_stream_set_skip(stream, skip_handler_apr);
-  svn_stream_set_mark(stream, mark_handler_apr);
-  svn_stream_set_seek(stream, seek_handler_apr);
+
+  if (supports_seek)
+{
+  svn_stream_set_skip(stream, skip_handler_apr);
+  svn_stream_set_mark(stream, mark_handler_apr);
+  svn_stream_set_seek(stream, seek_handler_apr);
+}
+
   svn_stream_set_data_available(stream, data_available_handler_apr);
   svn_stream__set_is_buffered(stream, is_buffered_handler_apr);
   stream->file = file;
@@ -1085,6 +1092,14 @@ svn_stream_open_unique(svn_stream_t **stream,
   return stream;
 }
 
+svn_stream_t *
+svn_stream_from_aprfile2(apr_file_t *file,
+ svn_boolean_t disown,
+ apr_pool_t *pool)
+{
+  return svn_error_trace(make_stream_from_apr_file(file, disown, TRUE, pool));
+}
+
 apr_file_t *
 svn_stream__aprfile(svn_stream_t *stream)
 {
@@ -1829,13 +1844,11 @@ svn_stream_for_stdin(svn_stream_t **in, apr_pool_t
   if (apr_err)
 return svn_error_wrap_apr(apr_err, "Can't open stdin");
 
-  *in = svn_stream_from_aprfile2(stdin_file, TRUE, pool);
-
   /* STDIN may or may not support positioning requests, but generally
  it does not, or the behavior is implementation-specific.  Hence,
- we cannot safely advertise mark() and seek() support. */
-  svn_stream_set_mark(*in, NULL);
-  svn_stream_set_seek(*in, NULL);
+ we cannot safely advertise mark(), seek() and non-default skip()
+ support. */
+  *in = make_stream_from_apr_file(stdin_file, TRUE, FALSE, pool);
 
   return SVN_NO_ERROR;
 }
@@ -1851,13 +1864,11 @@ svn_stream_for_stdout(svn_stream_t **out, apr_pool
   if (apr_err)
 return svn_error_wrap_apr(apr_err, "Can't open stdout");
 
-  *out = svn_stream_from_aprfile2(stdout_file, TRUE, pool);
-
   /* STDOUT may or may not support positioning requests, but generally
  it does not, or the behavior is implementation-specific.  Hence,
- we cannot safely advertise mark() and seek() support. */
-  svn_stream_set_mark(*out, NULL);
-  svn_stream_set_seek(*out, NULL);
+ we cannot safely advertise mark(), seek() and non-default skip()
+ support. */
+  *out = make_stream_from_apr_file(stdout_file, TRUE, FALSE, pool);
 
   return SVN_NO_ERROR;
 }
@@ -1873,13 +1884,11 @@ svn_stream_for_stderr(svn_stream_t **err, apr_pool
   if (apr_err)
 return svn_error_wrap_apr(apr_err, "Can't open stderr");
 
-  *err = svn_stream_from_aprfile2(stderr_file, TRUE, pool);
-
   /* STDERR may or may not support positioning requests, but generally
  it does not, or the behavior is implementation-specific.  Hence,
- we cannot safely advertise mark() and seek() support. */
-  svn_stream_set_mark(*err, NULL);
-  svn_stream_set_seek(*err, NULL);
+ we cannot safely advertise mark(), seek() and 

svnfsfs stats division by zero on empty repository

[Philip Martin]

$ svnadmin create repo
$ svnfsfs stats repo
...
Extensions by number of representations:
Floating point exception

Program received signal SIGFPE, Arithmetic exception.
0x0040311c in print_extensions_by_changes (stats=0x61bf10, 
pool=0x60c450) at ../src/subversion/svnfsfs/stats-cmd.c:249
249  (int)((stats->file_histogram.total.count - sum) * 100 /
(gdb) l
244 }
245 
246   printf(_("%11s %20s (%2d%%) representations\n"),
247  "(others)",
248  svn__ui64toa_sep(stats->file_histogram.total.count - sum, ',', 
pool),
249  (int)((stats->file_histogram.total.count - sum) * 100 /
250stats->file_histogram.total.count));
251 }
252 
253 /* Print the (up to) 16 extensions in STATS with the largest total size 
of
(gdb) p stats->file_histogram.total.count
$1 = 0

-- 
Philip Martin
WANdisco

Re: svn commit: r1701633 - /subversion/trunk/subversion/libsvn_subr/stream.c

[Evgeny Kotkov]

Ivan Zhakov  writes:

>> Indeed, I missed that default skip_handler_apr() performs a seek that could
>> be unavailable or behave surprisingly when used with a handle like STDIN.
>> So, the fix is partial.
>>
>> What do you think about the attached patch?
>>
> Looks good for me.

I committed this change in r1701792, r1701797 and extended the corresponding
backport proposal.


Regards,
Evgeny Kotkov