RE: svn copy WC URL fails silently

[John.Aasen]

Thanks for the help. Look like I need to see if it is possible to install svn 
version 1.8

John

-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
Sent: 6. januar 2015 05:57
To: Philip Martin
Cc: Aasen, John; 
Subject: Re: svn copy WC URL fails silently

On Mon, Jan 5, 2015 at 12:54 PM, Philip Martin  
wrote:
> Nico Kadel-Garcia  writes:
>
>>> I am having trouble with the svn copy command. I am running RedHat
>>> Enterprise Linux Workstation release 6.3 and svn version 1.6.1
>>> (r934486).
>>
>> Do you have a test environment you'd be willing to test 1.7 or 1.8 on?
>> 1.6.11 is no longer supported.
>
> svnadmin create repo --compatible-version 1.6 svn import -mm
> repo/format file://`pwd`/repo/f svnmucc -mm propset svn:externals '^/f
> x' file://`pwd`/repo svn co file://`pwd`/repo wc echo xx > wc/x svn cp
> -mm wc/x ^/copy
>
> Using 1.6 the copy does nothing and fails to create a revision. Using
> 1.7 the copy causes the client to abort with an assert.  Using 1.8 the
> copy creates a new revision.

Sorry about the blank mesage! So in general, perhaps file externals are simply 
not working up to your requirements before Subversoin 1.8?



CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be 
proprietary, confidential or subject to export regulations, and is only meant 
for the intended recipient(s). Any disclosure, copying, distribution or use is 
prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in 
error, please delete it immediately from your system and notify the sender 
properly.

Re: --with-zlib seems to have no effect on libsvn_delta

[Philip Martin]

亚男（Timandes）  writes:

> This is my configuration options:
>
>  # ./configure --prefix=/usr/local/subversion-1.8.11 \
>   --with-apr=/usr/local/apr-1.4.6/bin/apr-1-config \
>   --with-apr-util=/usr/local/apr-util-1.5.1/bin/apu-1-config 、
>   --with-sqlite=/usr/local/sqlite-autoconf-3071501 、
>   --with-zlib=/usr/local/zlib-1.2.8
>
> after that, is:
> # make && make install
>
> But when i try to use it, i found this warning:
> # /usr/local/subversion-1.8.11/bin/svn --version
> /usr/local/subversion-1.8.11/bin/svn: /lib64/libz.so.1: no version
> information available (required by
> /usr/local/subversion-1.8.11/lib/libsvn_delta-1.so.0)
> svn, version 1.8.11 (r1643975)
> ...

--with-zlib has caused configure to find the local zlib however it has
not arranged for RPATH to be set in the shared libraries to find zlib in
the non-standard location.  You have two options:

  - run your current build using something like:

 LD_LIBRARY_PATH=/usr/local/zlib-1.2.8/lib

  - build again using something like

 LD_FLAGS=-Wl,-rpath,/usr/local/zlib-1.2.8/lib

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: --with-zlib seems to have no effect on libsvn_delta

[Stefan Sperling]

On Tue, Jan 06, 2015 at 09:00:42AM +0800, 亚男（Timandes） wrote:
> This is my configuration options:
> 
>  # ./configure --prefix=/usr/local/subversion-1.8.11 \
>   --with-apr=/usr/local/apr-1.4.6/bin/apr-1-config \
>   --with-apr-util=/usr/local/apr-util-1.5.1/bin/apu-1-config 、
>   --with-sqlite=/usr/local/sqlite-autoconf-3071501 、
>   --with-zlib=/usr/local/zlib-1.2.8
> 
> after that, is:
> # make && make install
> 
> But when i try to use it, i found this warning:
> # /usr/local/subversion-1.8.11/bin/svn --version
> /usr/local/subversion-1.8.11/bin/svn: /lib64/libz.so.1: no version
> information available (required by
> /usr/local/subversion-1.8.11/lib/libsvn_delta-1.so.0)
> svn, version 1.8.11 (r1643975)
> ...
> 
> Then i realize that configure program maybe use pre-installed zlib in my
> system.
> # ldd /usr/local/subversion/lib/libsvn_delta-1.so.0|grep libz
> /usr/local/subversion/lib/libsvn_delta-1.so.0: /lib64/libz.so.1: no version
> information available (required by
> /usr/local/subversion/lib/libsvn_delta-1.so.0)
> libz.so.1 => /lib64/libz.so.1 (0x7ff5c959c000)
> 
> Other information:
> # ln -s /usr/local/subversion-1.8.11 /usr/local/subversion
> 
> # uname -a
> Linux log4.zg.zwt.qihoo.net 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22
> GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
> 
> # cat /etc/redhat-release
> CentOS release 6.2 (Final)
> 
> # rpm -qa|grep zlib
> zlib-1.2.3-27.el6.x86_64
> 
> # ll /usr/local/zlib-1.2.8/
> total 12
> drwxr-xr-x 2 root root 4096 Oct 16 09:20 include
> drwxr-xr-x 3 root root 4096 Oct 16 09:20 lib
> drwxr-xr-x 3 root root 4096 Oct 16 09:20 share
> 
> Part of config.log:
> ...
> configure:21895: zlib library configuration
> configure:21902: checking zlib.h usability
> configure:21902: gcc -c -g -O2  -g -O2 -pthread   -DLINUX=2 -D_REENTRANT
> -D_GNU_SOURCE -I/usr/local/zlib-1.2.8/include conftest.c >&5
> configure:21902: $? = 0
> configure:21902: result: yes
> configure:21902: checking zlib.h presence
> configure:21902: gcc -E   -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
> -I/usr/local/zlib-1.2.8/include conftest.c
> configure:21902: $? = 0
> configure:21902: result: yes
> configure:21902: checking for zlib.h
> configure:21902: result: yes
> configure:21910: checking for inflate in -lz
> configure:21935: gcc -o conftest -g -O2  -g -O2 -pthread   -DLINUX=2
> -D_REENTRANT -D_GNU_SOURCE -I/usr/local/zlib-1.2.8/include
> -L/usr/local/zlib-1.2.8/lib conftest.c -lz   >&5
> configure:21935: $? = 0
> configure:21944: result: yes
> ...
> ac_cv_header_zlib_h=yes
> ...
> LDFLAGS='   -L/usr/local/zlib-1.2.8/lib'
> ...
> SVN_ZLIB_INCLUDES='-I/usr/local/zlib-1.2.8/include'
> SVN_ZLIB_LIBS='-lz'
> ...

This is likely a problem caused by libtool.

libtool passes several -L flags to the linker, one for each library
directory used during the build. Sometimes these -L flags are passed
in the wrong order.

My guess is that there is another library (not zlib) in /lib64 used by
the build. If libtool generates linker arguments which contain -L/lib64
before -L/usr/local/zlib-1.2.8/lib the linker finds libz in /lib64 first!

To verify if this theory, run libtool in debug mode and check the linker
arguments used. For example:

  $ touch subversion/libsvn_subr/compress.c
  $ make subversion/libsvn_subr/libsvn_subr-1.la
  /bin/sh "/home/stsp/svn/svn-trunk/libtool" --tag=CC --silent --mode=compile 
gcc -std=c89 ...

You see a long libtool command line which includes the --silent option.
Copy-paste the entire command line and replace --silent with --debug, and
run it. You'll see the argument list libtool is generating for the linker.
Is -L/lib64 before -L/usr/local/zlib-1.2.8/lib?

I had the same problem and could only work around it by not using any
dependencies from a library directory I did not want the build to use.

So if you don't use any library from /lib64 this problem should disappear.

You could install other dependencies (such as APR, sqlite, etc.) into
/usr/local/ and make the build use them, too.

Re: Segmentation Fault with SVN Client related to serf

[Philip Martin]

 writes:

> viretp@mwbox:~$ svn ls https://127.0.0.1:7771/svn/t_sponis_testrepo
> Segmentation fault
>
> In /var/log/syslog:
> Jan  5 14:31:23 mwbox kernel: [14750.072747] svn[21822]: segfault at 
> 7f3733f39000 ip 7f37328ae3cf sp 7fff9e3df468 error 7 in 
> libc-2.13.so[7f373278a000+182000]
>
>
> Here the stacktrace with gdb:
>  
> (gdb) bt
> #0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2833
> #1  0x735f6fa3 in serf_bstrmemdup () from 
> /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> #2  0x735faecb in ?? () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> #3  0x735fb2d4 in serf_bucket_response_status () from 
> /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> #4  0x735fe219 in serf__handle_auth_response () from 
> /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> #5  0x735f4f29 in serf__process_connection () from 
> /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> #6  0x735f38ae in serf_event_trigger () from 
> /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> #7  0x735f39d9 in serf_context_run () from 
> /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> #8  0x7573b522 in svn_ra_serf__context_run_wait () from 
> /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1

What sort of authentication are you using on your proxy and webserver?
Is there authentication for the proxy?  Is the client handling proxy or
apache authentication when it crashed?  Are you using one of the
password stores?  It might be helpful to look at the network traffic
although this can be tricky with https.  One way that may work is to use
a socat proxy:

   socat -v TCP-LISTEN:9630,reuseaddr,fork OPENSSL:127.0.0.1:7771,verify=0

and then use http://localhost:9630/ instead of https://localhost:7771/
in your Subversion command. You may need to use TCP6-LISTEN.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

AW: Segmentation Fault with SVN Client related to serf

[pierre.viret]

> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Dienstag, 6. Januar 2015 12:49
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: Segmentation Fault with SVN Client related to serf
> 
>  writes:
> 
> > viretp@mwbox:~$ svn ls https://127.0.0.1:7771/svn/t_sponis_testrepo
> > Segmentation fault
> >
> > In /var/log/syslog:
> > Jan  5 14:31:23 mwbox kernel: [14750.072747] svn[21822]: segfault at
> > 7f3733f39000 ip 7f37328ae3cf sp 7fff9e3df468 error 7 in
> > libc-2.13.so[7f373278a000+182000]
> >
> >
> > Here the stacktrace with gdb:
> >
> > (gdb) bt
> > #0  __memcpy_ssse3 () at
> > ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2833
> > #1  0x735f6fa3 in serf_bstrmemdup () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #2  0x735faecb in ?? () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #3  0x735fb2d4 in serf_bucket_response_status () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #4  0x735fe219 in serf__handle_auth_response () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #5  0x735f4f29 in serf__process_connection () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #6  0x735f38ae in serf_event_trigger () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #7  0x735f39d9 in serf_context_run () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #8  0x7573b522 in svn_ra_serf__context_run_wait () from
> > /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
> 
> What sort of authentication are you using on your proxy and webserver?
> Is there authentication for the proxy?  Is the client handling proxy or apache
> authentication when it crashed?  Are you using one of the password stores?  It
> might be helpful to look at the network traffic although this can be tricky 
> with https.
> One way that may work is to use a socat proxy:
> 
>socat -v TCP-LISTEN:9630,reuseaddr,fork OPENSSL:127.0.0.1:7771,verify=0
> 
> and then use http://localhost:9630/ instead of https://localhost:7771/ in your
> Subversion command. You may need to use TCP6-LISTEN.
> 
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*

Here a description of the architecture we are using:
- a http-proxy is running on 127.0.0.1:7771 which builds a secure https tunnel 
to a special reverse proxy, using a certificate from a smart-card
- the reverse proxy then connects to the apache server used as subversion server
- the apache server uses a proprietary module for authentication using a 
security token placed in the http header.
- there is no authentication between the svn client and the local http-proxy
- the svn client is not aware that it connects through a proxy

I have tried using http instead of https for the connection between the svn 
client and the local proxy but in this case we get the segmentation fault by 
each call and not only 30% of the times...
The stacktrace looks very similar (I have pasted it at the end of the mail).

About network traffic: I have analysed the traffic between the local http-proxy 
and the svn client because I had supposed that some packet length was wrongly 
set, but could not find any clue about the reason for the segmentation fault. I 
have compared the traffic (with a svn client 1.6) between using neon and using 
serf but could not find anything explaining the segmentation fault in the case 
we use serf.



viretp@mwbox:~/work/APLAT-105/tests/debian$ gdb svn
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/svn...(no debugging symbols found)...done.
(gdb) run ls http://127.0.0.1:7771/svn/t_sponis_testrepo
Starting program: /usr/bin/svn ls http://127.0.0.1:7771/svn/t_sponis_testrepo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2833
2833../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory.
(gdb) bt
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2833
#1  0x735f6fa3 in serf_bstrmemdup () from 
/usr/lib/x86_64-linux-gnu/libserf-1.so.1
#2  0x735faecb in ?? () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
#3  0x735fb2d4 in serf_bucket_response_status () from 
/usr/lib/x86_64-linux-gnu/libserf-1.so.1
#4  0x735fe219 in serf__handle_auth_response () from 
/usr/lib/x86_64-linux-gnu/libserf-1.so.1
#5  0x735f4f29 in se

mod_dav_svn.so does no more support lock functions

[Thierry LEPINE]

What we had from 2006 : 
- subversion 1.3.0 server (Msi) over apache web serveur 2.0.55 on Windows SBS 
2003 32bits 
- Tortoise SVN 1.8.x clients connected to subversion on https

We could do every svn operation and also get / release lock, commit with lock.

We have switched last week to 
- subversion 1.8.11 server (Msi) over wamp 2.5 (apache server 2.4.9 - 32bits ) 
on Windows Server 2012 64bits 
- Tortoise SVN 1.8.x clients connected to subversion on https

We can do every svn operation but can't get/release lock, commit with lock.
When we try to get a lock on a file we have the following message on tortoise 
  Error sqlite[S19] :  NOT NULL constraint failed : LOCK.lock_token
  Error Additionnal errors :
  Error sqlite[S19] :  NOT NULL constraint failed : LOCK.lock_token
So the operation failed !

The error-log on the apache server contains
[Tue Jan 06 14:34:39.169863 2015] [dav:error] [pid 3760:tid 1164] [client 
192.168.2.xx:64852] Tried to attach multiple locks to a resource.  [400, #405]

The access-log on the apache server contains
192.168.2.xx - DOMAIN\\User [06/Jan/2015:14:34:39 +0100] "LOCK 
/repository/file_name HTTP/1.1" 400 364

We have downgraded the configuration to 
- subversion 1.7.17 server (Zip) over wamp 2.5 (apache server 2.4.9 - 32bits ) 
on Windows Server 2012 64bits 
- Tortoise SVN 1.8.x clients connected to subversion on https

We also can't use the lock functions like with subversion 1.8 !

Same case in November 2013 at 
http://svn.haxx.se/users/archive-2013-11/0107.shtml -> not solved
Same case in archive in January 2014 
http://subversion.1072662.n5.nabble.com/Possible-bug-in-SVN-1-8-3-and-1-8-4-file-locking-td186843.html
  -> not solved 

What we know is that it is working with subversion 1.6.x / apache 2.2 on Ubuntu 
!
Do we have to downgrade so deep ? 
Why such versions exist 1.7 & 1.8 if they don't work anymore ? 
Is it just a problem with apache 2.4 ?



Thierry

 www.indeep.fr

Re: AW: Segmentation Fault with SVN Client related to serf

[Philip Martin]

 writes:

> Here a description of the architecture we are using:
> - a http-proxy is running on 127.0.0.1:7771 which builds a secure
>   https tunnel to a special reverse proxy, using a certificate from a
>   smart-card
> - the reverse proxy then connects to the apache server used as
>   subversion server
> - the apache server uses a proprietary module for authentication using
>   a security token placed in the http header.
> - there is no authentication between the svn client and the local http-proxy
> - the svn client is not aware that it connects through a proxy
>
> I have tried using http instead of https for the connection between
> the svn client and the local proxy but in this case we get the
> segmentation fault by each call and not only 30% of the times...  The
> stacktrace looks very similar (I have pasted it at the end of the
> mail).
>
> About network traffic: I have analysed the traffic between the local
> http-proxy and the svn client because I had supposed that some packet
> length was wrongly set, but could not find any clue about the reason
> for the segmentation fault. I have compared the traffic (with a svn
> client 1.6) between using neon and using serf but could not find
> anything explaining the segmentation fault in the case we use serf.

The crash is happening in the code that parses the status line,
i.e. when handling something like

  HTTP/1.1 200 OK

or

  HTTP/1.1 207 Multi-Status

or 

  HTTP/1.1 401 Authorization Required

Typically the client will first send an OPTIONS request and get back a
401 or a 200.  The client will then send further OPTIONS and PROPFIND
requests.  Can you identify which request and response is causing the
crash?  Also which, if any, requests are processed without problem
before the one that causes the crash?

It possible that something in the final request is causing the problem
but it's also possible that something in one of the earlier requests is
not handled correctly and that is the cause of the problem.  So we
really need to know the whole sequence of requests that get sent.  I
don't know how much debugging you can do with the Debian binary, it
might be easier if you install the libserf1-dbg package.  This is the
code that appears to be crashing:

Breakpoint 1, parse_status_line (ctx=0x46b758, allocator=0x4623e0)
at buckets/response_buckets.c:148
148 ctx->sl.reason = serf_bstrmemdup(allocator, reason,
(gdb) l
143 if (apr_isspace(*reason)) {
144 reason++;
145 }
146 
147 /* Copy the reason value out of the line buffer. */
148 ctx->sl.reason = serf_bstrmemdup(allocator, reason,
149  ctx->linebuf.used
150  - (reason - ctx->linebuf.line));
151 
152 return APR_SUCCESS;
(gdb) p ctx->linebuf.used
$8 = 15
(gdb) x/15c ctx->linebuf.line
0x46b788:   72 'H'  84 'T'  84 'T'  80 'P'  47 '/'  49 '1'  46 '.'  49 '1'
0x46b790:   32 ' '  50 '2'  48 '0'  48 '0'  32 ' '  79 'O'  75 'K'
(gdb) p reason
$9 = 0x46b795 "OKext/html; charset=iso-8859-1ry\"OpenSSL/1.0.1e DAV"

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: AW: Segmentation Fault with SVN Client related to serf

[Stefan Sperling]

On Tue, Jan 06, 2015 at 02:01:52PM +, Philip Martin wrote:
> The crash is happening in the code that parses the status line,
> i.e. when handling something like
> 
>   HTTP/1.1 200 OK
> 
> or
> 
>   HTTP/1.1 207 Multi-Status
> 
> or 
> 
>   HTTP/1.1 401 Authorization Required


> Breakpoint 1, parse_status_line (ctx=0x46b758, allocator=0x4623e0)
> at buckets/response_buckets.c:148
> 148   ctx->sl.reason = serf_bstrmemdup(allocator, reason,
> (gdb) l
> 143   if (apr_isspace(*reason)) {
> 144   reason++;
> 145   }
> 146   
> 147   /* Copy the reason value out of the line buffer. */
> 148   ctx->sl.reason = serf_bstrmemdup(allocator, reason,
> 149ctx->linebuf.used
> 150- (reason - ctx->linebuf.line));
> 151   
> 152   return APR_SUCCESS;
> (gdb) p ctx->linebuf.used
> $8 = 15
> (gdb) x/15c ctx->linebuf.line
> 0x46b788: 72 'H'  84 'T'  84 'T'  80 'P'  47 '/'  49 '1'  46 '.'  49 '1'
> 0x46b790: 32 ' '  50 '2'  48 '0'  48 '0'  32 ' '  79 'O'  75 'K'
> (gdb) p reason
> $9 = 0x46b795 "OKext/html; charset=iso-8859-1ry\"OpenSSL/1.0.1e DAV"

Note that this code fails to check for errors from apr_strtoi64().
The bytes beyond the status code number aren't verified but apr_strtoi64()
will try to parse them and perhaps fail.

This patch against serf trunk adds error checking.
It may not fix the segfault problem, though.

Index: buckets/response_buckets.c
===
--- buckets/response_buckets.c  (revision 2445)
+++ buckets/response_buckets.c  (working copy)
@@ -140,6 +140,8 @@ static apr_status_t parse_status_line(response_con
 ctx->sl.version = SERF_HTTP_VERSION(ctx->linebuf.line[5] - '0',
 ctx->linebuf.line[7] - '0');
 ctx->sl.code = apr_strtoi64(ctx->linebuf.line + 8, &reason, 10);
+if (errno == ERANGE || reason == ctx->linebuf.line + 8)
+return SERF_ERROR_BAD_HTTP_RESPONSE;
 
 /* Skip leading spaces for the reason string. */
 if (apr_isspace(*reason)) {

AW: AW: Segmentation Fault with SVN Client related to serf

[pierre.viret]

> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Dienstag, 6. Januar 2015 15:02
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: Segmentation Fault with SVN Client related to serf
> 
[...]
> 
> It possible that something in the final request is causing the problem but 
> it's also
> possible that something in one of the earlier requests is not handled 
> correctly and
> that is the cause of the problem.  So we really need to know the whole 
> sequence
> of requests that get sent.  I don't know how much debugging you can do with 
> the
> Debian binary, it might be easier if you install the libserf1-dbg package.  
> This is the
> code that appears to be crashing:
> 
[...]

You asked for the whole sequence of request, here is the whole tracing of our 
proxy: I hope this helps. But as already said: the svn client does not crash 
always but 30% of the times we execute exactly the same ls command.

2015-01-06 15:43:24,111 DEBUG ProxyHttpHandler - >OPTIONS 
/svn/t_sponis_testrepo HTTP/1.1
2015-01-06 15:43:24,111 DEBUG ProxyHttpHandler - Opening connection to URL: 
https://tpfesa101.pnet.ch:443/svn/t_sponis_testrepo
2015-01-06 15:43:24,112 TRACE DAVHttpsURLConnection - Creating for 
https://tpfesa101.pnet.ch:443/svn/t_sponis_testrepo
2015-01-06 15:43:24,112 DEBUG DAVHttpsURLConnection - setRequestMethod(OPTIONS)
2015-01-06 15:43:24,112 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning GET
2015-01-06 15:43:24,112 DEBUG DAVHttpsURLConnection - replace method value 
'GET' in internal delegate with new value 'OPTIONS'
2015-01-06 15:43:24,114 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:43:24,114 DEBUG ProxyHttpHandler - Size of request headers: 7
2015-01-06 15:43:24,114 DEBUG ProxyHttpHandler - >Content-type: text/xml
2015-01-06 15:43:24,114 DEBUG ProxyHttpHandler - >Host: 127.0.0.1:7771
2015-01-06 15:43:24,114 DEBUG ProxyHttpHandler - >Accept-encoding: gzip
2015-01-06 15:43:24,114 DEBUG ProxyHttpHandler - >Content-length: 131
2015-01-06 15:43:24,114 DEBUG ProxyHttpHandler - >Dav: 
http://subversion.tigris.org/xmlns/dav/svn/depth,http://subversion.tigris.org/xmlns/dav/svn/mergeinfo,http://subversion.tigris.org/xmlns/dav/svn/log-revprops
2015-01-06 15:43:24,115 DEBUG ProxyHttpHandler - >Connection: keep-alive
2015-01-06 15:43:24,115 DEBUG ProxyHttpHandler - >User-agent: SVN/1.8.10 
(x86_64-pc-linux-gnu) serf/1.3.7
2015-01-06 15:43:24,115 DEBUG ProxyHttpHandler - Connecting to server...
2015-01-06 15:43:24,115 TRACE DAVHttpsURLConnection - connect()
2015-01-06 15:43:24,115 DEBUG SslSocketFactory - Creating an unconnected 
SSLSocket()
2015-01-06 15:43:24,130 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:43:24,131 DEBUG DAVHttpsURLConnection - getOutputStream() with 
method == OPTIONS
2015-01-06 15:43:24,131 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:43:24,131 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:43:24,131 DEBUG DAVHttpsURLConnection - replace method value 
'OPTIONS' in internal delegate with new value 'TRACE'
2015-01-06 15:43:24,132 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning TRACE
2015-01-06 15:43:24,132 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning TRACE
2015-01-06 15:43:24,132 DEBUG DAVHttpsURLConnection - replace method value 
'TRACE' in internal delegate with new value 'OPTIONS'
2015-01-06 15:43:24,132 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:43:24,132 TRACE ProxyHttpHandler - Read 131 bytes from client
2015-01-06 15:43:24,133 TRACE ProxyHttpHandler - >
2015-01-06 15:43:24,133 DEBUG ProxyHttpHandler - Total number of bytes read 
from client: 131
2015-01-06 15:43:24,133 DEBUG AplatCookieHandler - Retrieve all cookies for 
URI: https://tpfesa101.pnet.ch:443/svn/t_sponis_testrepo
2015-01-06 15:43:24,133 DEBUG AplatCookieHandler - Append cookie: 
Navajo=gIb1uQ8SXfzepKGZcXFbI+zNrwxwqAIM+CUI4LudfRTv09laT7Q6NBLoYO/gwjS9TUtIvk8ia94-
2015-01-06 15:43:24,259 DEBUG AplatCookieHandler - save cookies from URI: 
https://tpfesa101.pnet.ch:443/svn/t_sponis_testrepo
2015-01-06 15:43:24,259 DEBUG ProxyHttpHandler - <200 OK
2015-01-06 15:43:24,260 DEBUG ProxyHttpHandler - Size of response headers: 23
2015-01-06 15:43:24,260 DEBUG ProxyHttpHandler - 

Re: AW: Segmentation Fault with SVN Client related to serf

[Stefan Sperling]

On Tue, Jan 06, 2015 at 02:01:52PM +, Philip Martin wrote:
> Typically the client will first send an OPTIONS request and get back a
> 401 or a 200.  The client will then send further OPTIONS and PROPFIND
> requests.  Can you identify which request and response is causing the
> crash?  Also which, if any, requests are processed without problem
> before the one that causes the crash?

I would be interested in knowing which end-of-line terminators each
line in the auth request header is using.
Are some lines terminated with LF, and some with CRLF?

Re: mod_dav_svn.so does no more support lock functions

[Philip Martin]

Thierry LEPINE  writes:

> We have switched last week to 
> - subversion 1.8.11 server (Msi) over wamp 2.5 (apache server 2.4.9 - 32bits 
> ) on Windows Server 2012 64bits 

> The error-log on the apache server contains
> [Tue Jan 06 14:34:39.169863 2015] [dav:error] [pid 3760:tid 1164] [client 
> 192.168.2.xx:64852] Tried to attach multiple locks to a resource.  [400, #405]

Locking does work in 1.8.  This problem has only ever been reported by
people using Windows and it appears to be some binary incompatibity
between Apache and Subversion caused by the way they have been compiled.
Using different binaries has been reported to solve the problem.

A recent report: http://svn.haxx.se/users/archive-2014-02/0020.shtml

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

RE: mod_dav_svn.so does no more support lock functions

[Thierry LEPINE]

> Locking does work in 1.8.  This problem has only ever been reported by
> people using Windows and it appears to be some binary incompatibity
> between Apache and Subversion caused by the way they have been compiled.
> Using different binaries has been reported to solve the problem.

For sure, but no one says how it has made it ! 
Which binary compiled by which compiler and what is the winning couple ?

We are only using official binaries to avoid mistake, so with official ones it 
does not work , that is my status and the reason of my request !

> A recent report: http://svn.haxx.se/users/archive-2014-02/0020.shtml

> -- 
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*

Re: mod_dav_svn.so does no more support lock functions

[Philip Martin]

Thierry LEPINE  writes:

> We are only using official binaries to avoid mistake, so with official
> ones it does not work , that is my status and the reason of my request!

There are no official binaries; the only official release is the source
code.  Where did you get your binaries?  Did you get Apache and
Subversion from the same place?

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

RE: mod_dav_svn.so does no more support lock functions

[Thierry LEPINE]

>> We are only using official binaries to avoid mistake, so with official
>> ones it does not work , that is my status and the reason of my request!
>
> There are no official binaries; the only official release is the source
> code.  Where did you get your binaries?  Did you get Apache and
> Subversion from the same place?

Not the official for sure but the most common download site

http://sourceforge.net/projects/wampserver/ 

http://sourceforge.net/projects/win32svn/

Re: mod_dav_svn.so does no more support lock functions

[Dave Huang]

On 2015-01-06 10:57, Thierry LEPINE wrote:

Not the official for sure but the most common download site

http://sourceforge.net/projects/wampserver/

http://sourceforge.net/projects/win32svn/


http://www.wampserver.com/en/ says "Once WampServer is installed, you 
can manually add aditionals Apache, Php or MySql (only VC9, VC10 and 
VC11 compiled) versions." I think that means addon modules must be 
compiled with VC9, 10, or 11. http://sourceforge.net/projects/win32svn/ 
says that the SVN modules are build with VC++ 6.0.


I think you need to get binaries of Apache and SVN that have been 
compiled with compatible compilers. I'm using the 
http://www.apachehaus.com/ binaries, and they're working well.


--
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Authentication Questions

[JT . Miller]

Debugging other issues, I turned on verbose logging and was curious if the 
below traffic was typical. This may well be correct, as we have path-based 
authentication requiring valid NTLM users. Server is Windows 2008 R2, Apache 
2.4, NTLM, and SVN 1.8. 

[Tue Jan 06 15:18:28.378306 2015] [authz_core:debug] [pid 15392:tid 16884] 
mod_authz_core.c(799): [client USER_IP:9] AH01626: authorization result of 
Require valid-user : denied (no authenticated user yet)
[Tue Jan 06 15:18:28.378306 2015] [authz_core:debug] [pid 15392:tid 16884] 
mod_authz_core.c(799): [client USER_IP:9] AH01626: authorization result of 
: denied (no authenticated user yet)
[Tue Jan 06 15:18:28.378306 2015] [authnz_sspi:debug] [pid 15392:tid 16884] 
mod_authnz_sspi_authentication.c(439): [client USER_IP:9] SSPI1: 
Entering authenticate_sspi_user()
[Tue Jan 06 15:18:28.378306 2015] [authnz_sspi:debug] [pid 15392:tid 16884] 
mod_authnz_sspi_authentication.c(544): [client USER_IP:9] SSPI9: 
Authenticated user: USER_NAME
[Tue Jan 06 15:18:28.378306 2015] [authz_svn:debug] [pid 15392:tid 16884] 
mod_authz_svn.c(400): [client USER_IP:9] Path to authz file is 
D:/svn/config/svnaccess.conf
[Tue Jan 06 15:18:28.378306 2015] [authz_svn:info] [pid 15392:tid 16884] 
[client USER_IP:9] Access granted: 'USER_NAME' GET REPO:/PATH_TO_FILE

There are hundreds to thousands of the above entry pattern for each user as 
they browse the repository (over 6 hours log is ~420MB with ~2.4M entries). 

I guess there's no caching of credentials since the path-based authentication 
file can change at any time?

Regards,

JT Miller
L-3 Mustang Technology