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

[pierre.viret]

> -Ursprüngliche Nachricht-
> Von: Stefan Sperling [mailto:s...@elego.de]
> Gesendet: Dienstag, 6. Januar 2015 15:59
> An: Philip Martin
> Cc: Viret Pierre, PF54; users@subversion.apache.org
> Betreff: Re: AW: Segmentation Fault with SVN Client related to serf
> 
> 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?

I'm not sure what you mean about auth request because in our case the svn 
client does not use authentication. How can I find the header you mean? What is 
it's name?

Remarque concernant la sécurité:
Ce courriel provenant de PostFinance est signé. Vous trouverez d'autres 
informations à ce sujet sous: 
https://www.postfinance.ch/e-signature.
Ne divulguez jamais vos éléments de sécurité à des tiers.

smime.p7s
Description: S/MIME Cryptographic Signature

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

[Philip Martin]

 writes:

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

This is a bit confusing:

  2015-01-06 15:43:24,260 DEBUG ProxyHttpHandler - 
> 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 - > encoding="utf-8"?> xmlns:D="DAV:">
> 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 Apla

Getting E160013 error on recursive svn prop list command

[Grant Schoep]

I'm running
SVN client (svn, version 1.8.8 (r1568071, from Collabnet RPM) (NOTE I've
tried a few different SVN versions on different machines for client side,
same results)
SVN server is running Subversion Edge 4.0.5

So I was trying to get an external tool(Crucible) to interact with our SVN
database. It chokes part way through. Digging through the logs it looks
like there might be something wrong with our SVN database.

I can reproduce this just with SVN on the command line. This problem only
appears down a certain path in the repo, on a specific revision.

So if I execute the following command

svn proplist -R -r 17672
https:/blah:12345/svn/stuff/web_services/ihas/trunk/@17672

It starts listing lots of Properties, but then bombs out with the following
issue

svn: E160013:
'/svn/stuff/!svn/rvr/17672/web_services/ihas/trunk/tmp/cache/assets/CDC/D90/752d90f7f232adf53395237b2d437a3a'
path not found

The exact part that is "not found" isn't always the same. But it is always
something in the "tmp" directory

If I refine the proplist a bit more and specify
svn proplist -R -r 17672
https:/blah:12345/svn/stuff/web_services/ihas/trunk/tmp/@17672

I get the same error, but it never seems to list anything.

So my feeling is something in this tmp revisioned directory is corrupt?

I ran an "svnadmin verify repopath" on this thing and it didn't report any
errors.

I am really at a loss of what to look at here. Any ideas of what to look at?

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

[pierre.viret]

> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Mittwoch, 7. Januar 2015 14:51
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
> 
[...]
> This is a bit confusing:
> 
>   2015-01-06 15:43:24,260 DEBUG ProxyHttpHandler -    2015-01-06 15:43:24,261 DEBUG ProxyHttpHandler - Do not send null key back
> to client null: HTTP/1.1 200 OK
> 
> That's the HTTP status line so why the message about not sending it back to 
> the
> client?  I'd expect everything to break if the proxy doesn't send the status 
> line
> back.  Is the proxy really blocking the status line?
> It's hard to believe so I think the message must mean something else.
> If you were to use a socat proxy between the client and your main proxy we 
> could
> see exactly what the client is receiving.
> 
> I see the client sending 2 OPTIONS requests which is typical for a modern 
> client
> negotiating Subversion's v2 protocol.  The first server response contains 
> SVN-Me-
> Resource indicating a modern server that supports v2, but the second response
> does not include it.  Why did the server stop supporting v2?  Is there some 
> sort of
> load balancer sending requests to multiple servers, or some sort of HTTP 
> caching?
> Almost all the headers are missing from the second OPTIONS repsonse.
> 
> The client goes on to send v1 PROPFIND requests to !svn/vcc/default and
> !svn/bln, so the second OPTIONS response appears to have prevented the
> v2 protocol being used.
> 
> It's still not clear to me why the client fails but it may be hard to 
> reproduce outside
> of your environment given the strange behaviour of the server.
> 
> 
The status line is not blocked. The debugging message means that we have got an 
header with a null key and with the status line as value: in this case the 
header is not added to the request sent back to the client. This seems to be 
common that some HTTP Implementations return such a null key header in the list 
of headers of a request.

I don't think that we would get more informations using socat because our http 
proxy should debug everything it gets, but I could give it a try.

We are using subversion server version 1.8.10: maybe is the behavior there 
other than with older versions?

I send you here the debugging output in case the "svn ls" command runs without 
crash: this could help to understand the problem.

2015-01-06 15:36:28,358 TRACE DAVHttpsURLConnection - Creating for 
https://tpfesa101.pnet.ch:443/svn/t_sponis_testrepo
2015-01-06 15:36:28,358 DEBUG DAVHttpsURLConnection - setRequestMethod(OPTIONS)
2015-01-06 15:36:28,358 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning GET
2015-01-06 15:36:28,359 DEBUG DAVHttpsURLConnection - replace method value 
'GET' in internal delegate with new value 'OPTIONS'
2015-01-06 15:36:28,359 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:36:28,359 DEBUG ProxyHttpHandler - Size of request headers: 7
2015-01-06 15:36:28,359 DEBUG ProxyHttpHandler - >Content-type: text/xml
2015-01-06 15:36:28,359 DEBUG ProxyHttpHandler - >Host: 127.0.0.1:7771
2015-01-06 15:36:28,359 DEBUG ProxyHttpHandler - >Accept-encoding: gzip
2015-01-06 15:36:28,359 DEBUG ProxyHttpHandler - >Content-length: 131
2015-01-06 15:36:28,360 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:36:28,360 DEBUG ProxyHttpHandler - >Connection: keep-alive
2015-01-06 15:36:28,360 DEBUG ProxyHttpHandler - >User-agent: SVN/1.8.10 
(x86_64-pc-linux-gnu) serf/1.3.7
2015-01-06 15:36:28,360 DEBUG ProxyHttpHandler - Connecting to server...
2015-01-06 15:36:28,360 TRACE DAVHttpsURLConnection - connect()
2015-01-06 15:36:28,360 DEBUG SslSocketFactory - Creating an unconnected 
SSLSocket()
2015-01-06 15:36:28,373 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:36:28,373 DEBUG DAVHttpsURLConnection - getOutputStream() with 
method == OPTIONS
2015-01-06 15:36:28,373 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:36:28,373 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:36:28,374 DEBUG DAVHttpsURLConnection - replace method value 
'OPTIONS' in internal delegate with new value 'TRACE'
2015-01-06 15:36:28,374 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning TRACE
2015-01-06 15:36:28,374 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning TRACE
2015-01-06 15:36:28,374 DEBUG DAVHttpsURLConnection - replace method value 
'TRACE' in internal delegate with new value 'OPTIONS'
2015-01-06 15:36:28,374 TRACE DAVHttpsURLConnection - getRequestMethod() 
returning OPTIONS
2015-01-06 15:36:28,374 TRACE ProxyHttpHandler - Read 131 bytes from c