You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2012/05/16 17:45:36 UTC

Trunk checkout fails with serf but not neon

I cannot recreate this with the Apache repository, but with a local
1.7.5 server and current trunk client I get this:

$ svn co http://cu121.cloud.sp.collab.net/svn/desktop desktop
--username=markphip --depth=immediates
subversion/svn/checkout-cmd.c:168: (apr_err=130003)
subversion/libsvn_client/checkout.c:103: (apr_err=130003)
subversion/libsvn_client/ra.c:495: (apr_err=130003)
subversion/libsvn_client/ra.c:362: (apr_err=130003)
subversion/libsvn_ra/ra_loader.c:500: (apr_err=130003)
svn: E130003: Unable to connect to a repository at URL
'http://cu121.cloud.sp.collab.net/svn/desktop'
subversion/libsvn_ra_serf/util.c:780: (apr_err=130003)
subversion/libsvn_ra_serf/util.c:737: (apr_err=130003)
subversion/libsvn_ra_serf/util.c:1959: (apr_err=130003)
subversion/libsvn_ra_serf/util.c:1940: (apr_err=130003)
subversion/libsvn_ra_serf/util.c:2389: (apr_err=130003)
svn: E130003: The OPTIONS response contains invalid XML (200 OK)
Abort trap: 6

Using Neon it works fine.

Any ideas where to look?

On the server, you just see this:

204.11.125.142 - - [16/May/2012:16:26:37 -0700] "OPTIONS /svn/desktop
HTTP/1.1" 401 401
204.11.125.142 - markphip [16/May/2012:16:26:40 -0700] "OPTIONS
/svn/desktop HTTP/1.1" 200 191

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Greg Stein <gs...@gmail.com>.
On May 16, 2012 4:06 PM, "Mark Phippard" <ma...@gmail.com> wrote:
>
> On Wed, May 16, 2012 at 4:04 PM, Greg Stein <gs...@gmail.com> wrote:
> >
> > On May 16, 2012 3:00 PM, "Justin Erenkrantz" <ju...@erenkrantz.com>
wrote:
> >>
> >> On Wed, May 16, 2012 at 11:54 AM, Mark Phippard <ma...@gmail.com>
> >> wrote:
> >> > NOTE the length stuff that happened in the middle of the response?
> >>
> >> Yah, that'd be a CDATA spanning TCP packets as socat puts in
> >> timestamps when a new packet arrives.
> >>
> >> So, yah, Greg's the most recent culprit in that space.  =P  -- justin
> >
> > Eh? How can my client work cause a server to send garbage?
> >
> > My work will detect the problem, where it likely got ignored before.
>
> I do not think the server sent garbage.  It sent a chunked response
> where the entire OPTIONS response did not come in one packet.  When
> this happens with the new code it seems to break.
>
> As Justin said, the date/time was simply inserted by socat in its
> output because it was a new packet.

Gotch. Likely I goofed something in 1337455. I'll see if I can repro
somehow.

Thx,
-g

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 4:12 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, May 16, 2012 at 4:06 PM, Mark Phippard <ma...@gmail.com> wrote:
>
>> I do not think the server sent garbage. �It sent a chunked response
>> where the entire OPTIONS response did not come in one packet. �When
>> this happens with the new code it seems to break.
>>
>> As Justin said, the date/time was simply inserted by socat in its
>> output because it was a new packet.
>
> I have attached all of the output when using socat as a proxy.

And here is attached output from a 1.7.5 client using Serf (which
handles the same OPTIONS response fine).


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 4:06 PM, Mark Phippard <ma...@gmail.com> wrote:

> I do not think the server sent garbage. �It sent a chunked response
> where the entire OPTIONS response did not come in one packet. �When
> this happens with the new code it seems to break.
>
> As Justin said, the date/time was simply inserted by socat in its
> output because it was a new packet.

I have attached all of the output when using socat as a proxy.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 4:04 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On May 16, 2012 3:00 PM, "Justin Erenkrantz" <ju...@erenkrantz.com> wrote:
>>
>> On Wed, May 16, 2012 at 11:54 AM, Mark Phippard <ma...@gmail.com>
>> wrote:
>> > NOTE the length stuff that happened in the middle of the response?
>>
>> Yah, that'd be a CDATA spanning TCP packets as socat puts in
>> timestamps when a new packet arrives.
>>
>> So, yah, Greg's the most recent culprit in that space.  =P  -- justin
>
> Eh? How can my client work cause a server to send garbage?
>
> My work will detect the problem, where it likely got ignored before.

I do not think the server sent garbage.  It sent a chunked response
where the entire OPTIONS response did not come in one packet.  When
this happens with the new code it seems to break.

As Justin said, the date/time was simply inserted by socat in its
output because it was a new packet.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Greg Stein <gs...@gmail.com>.
On May 16, 2012 3:00 PM, "Justin Erenkrantz" <ju...@erenkrantz.com> wrote:
>
> On Wed, May 16, 2012 at 11:54 AM, Mark Phippard <ma...@gmail.com>
wrote:
> > NOTE the length stuff that happened in the middle of the response?
>
> Yah, that'd be a CDATA spanning TCP packets as socat puts in
> timestamps when a new packet arrives.
>
> So, yah, Greg's the most recent culprit in that space.  =P  -- justin

Eh? How can my client work cause a server to send garbage?

My work will detect the problem, where it likely got ignored before.

Cheers,
-g

Re: Trunk checkout fails with serf but not neon

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, May 16, 2012 at 11:54 AM, Mark Phippard <ma...@gmail.com> wrote:
> NOTE the length stuff that happened in the middle of the response?

Yah, that'd be a CDATA spanning TCP packets as socat puts in
timestamps when a new packet arrives.

So, yah, Greg's the most recent culprit in that space.  =P  -- justin

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
Justin helped my get socat working on IRC.  For archives sake, I
basically am using it as a proxy.  I added localhost:8080 as my proxy
in servers and then it worked great.

Here is the response it logs in the failed request:

<?xml version="1.0" encoding="utf-8"?>
<D:options-response xmlns:D="DAV:">
<D:activity-collection-set><D:href>/svn/de< 2012/05/16 14:45:54.190315
 length=74 from=1852 to=1925
sktop/!svn/act/</D:href></D:activity-collection-set></D:options-response>

NOTE the length stuff that happened in the middle of the response?

This is a successful request:


<?xml version="1.0" encoding="utf-8"?>
<D:options-response xmlns:D="DAV:">
<D:activity-collection-set><D:href>/svn/desktop/!svn/act/</D:href></D:activity-collection-set></D:options-response>


I got these two responses just running svn up two times from the same
terminal prompt.  The first time, the command worked, the second time
it failed.

Mark

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 2:30 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Wed, May 16, 2012 at 11:29 AM, Mark Phippard <ma...@gmail.com> wrote:
>> Obviously I am not understanding how to use this tool.
>
> Ahh...you then run tcpdump against localhost port 8080 (probably
> requiring interface lo0).  socat just gets you around the VPN issue.

Should the SVN command have worked?  It seems like I did not enter the
socat command properly.  I changed it a little from what Philip
suggested because I was not sure how the request was going to get to
my server.

I thought socat was going to dump output to the screen.  Will try tcpdump.



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, May 16, 2012 at 11:29 AM, Mark Phippard <ma...@gmail.com> wrote:
> Obviously I am not understanding how to use this tool.

Ahh...you then run tcpdump against localhost port 8080 (probably
requiring interface lo0).  socat just gets you around the VPN issue.
-- justin

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 2:10 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Justin Erenkrantz <ju...@erenkrantz.com> writes:
>
>> On Wed, May 16, 2012 at 10:55 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> I am trying Wireshark but it says I do not have any interfaces it can
>>> use.  I am on a Macbook Air so maybe it needs an Ethernet adapter.
>>> Looking for other mac capture tools right now.
>>
>> As root, use:
>>
>> # tcpdump -w /tmp/mycapture.dump -i en0 -s 0 host cu121.cloud.sp.collab.net
>
> Or as an ordinary user:
>
> socat -v TCP-LISTEN:8080,reuseaddr,fork TCP4:localhost:http
>
> and then connect Subversion to port 8080.

Never used this program and Google help not great.  This is what I am trying:

In Terminal 1:

$ socat -v TCP-LISTEN:8080,reuseaddr,fork TCP4:cu121.cloud.sp.collab.net:http

In Terminal 2:

 $ svn co --depth=immediates http://localhost:8080/svn/desktop
subversion/svn/checkout-cmd.c:168: (apr_err=61)
subversion/libsvn_client/checkout.c:103: (apr_err=61)
subversion/libsvn_client/ra.c:495: (apr_err=61)
subversion/libsvn_client/ra.c:362: (apr_err=61)
subversion/libsvn_ra/ra_loader.c:500: (apr_err=61)
svn: E000061: Unable to connect to a repository at URL
'http://localhost:8080/svn/desktop'
subversion/libsvn_ra_serf/util.c:780: (apr_err=61)
subversion/libsvn_ra_serf/util.c:747: (apr_err=61)
svn: E000061: Error running context: Connection refused

Obviously I am not understanding how to use this tool.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Philip Martin <ph...@wandisco.com>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:

> On Wed, May 16, 2012 at 10:55 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I am trying Wireshark but it says I do not have any interfaces it can
>> use.  I am on a Macbook Air so maybe it needs an Ethernet adapter.
>> Looking for other mac capture tools right now.
>
> As root, use:
>
> # tcpdump -w /tmp/mycapture.dump -i en0 -s 0 host cu121.cloud.sp.collab.net

Or as an ordinary user:

socat -v TCP-LISTEN:8080,reuseaddr,fork TCP4:localhost:http

and then connect Subversion to port 8080.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: Trunk checkout fails with serf but not neon

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Wed, May 16, 2012 at 19:55:41 +0100:
> Mark Phippard <ma...@gmail.com> writes:
> 
> > Greg is working on.  I will try Philip's suggestion but assume I need
> > to read up on what he suggested so that I understand what I need to
> > do.
> 
> Something like this:
> 
> $ socat -v TCP4-LISTEN:8080,reuseaddr,fork TCP4:svn.apache.org:http
> 
> then in another window something like this:
> 
> $ svn ls http://localhost:8080/repos/asf/subversion
> 
> but it doesn't work quite as well as I expected.  I've only previously
> used socat to capture traffic between programs on the same machine.  The
> problem is that using socat as a proxy causes the Host: header sent to
> svn.apache.org to "127.0.0.1:8080" instead of "svn.apache.org".

So add '127.0.0.1 svn.apache.org' to /etc/hosts?

(and in case someone finds it useful:
curl -H "Host: svn.apache.org" http://localhost/repos/asf/subversion/README)

Re: Trunk checkout fails with serf but not neon

Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:

> Mark Phippard <ma...@gmail.com> writes:
>
>> Greg is working on.  I will try Philip's suggestion but assume I need
>> to read up on what he suggested so that I understand what I need to
>> do.
>
> Something like this:
>
> $ socat -v TCP4-LISTEN:8080,reuseaddr,fork TCP4:svn.apache.org:http
>
> then in another window something like this:
>
> $ svn ls http://localhost:8080/repos/asf/subversion
>
> but it doesn't work quite as well as I expected.  I've only previously
> used socat to capture traffic between programs on the same machine.  The
> problem is that using socat as a proxy causes the Host: header sent to
> svn.apache.org to "127.0.0.1:8080" instead of "svn.apache.org".

Setting servers:global:http-proxy-host and -port to 127.0.0.1 and 8080
and then running

$ svn ls http://svn.apache.org/repos/asf/subversion

allows socat to capture the traffic.

-- 
Philip

Re: Trunk checkout fails with serf but not neon

Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:

> Greg is working on.  I will try Philip's suggestion but assume I need
> to read up on what he suggested so that I understand what I need to
> do.

Something like this:

$ socat -v TCP4-LISTEN:8080,reuseaddr,fork TCP4:svn.apache.org:http

then in another window something like this:

$ svn ls http://localhost:8080/repos/asf/subversion

but it doesn't work quite as well as I expected.  I've only previously
used socat to capture traffic between programs on the same machine.  The
problem is that using socat as a proxy causes the Host: header sent to
svn.apache.org to "127.0.0.1:8080" instead of "svn.apache.org".

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 2:15 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Wed, May 16, 2012 at 11:10 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I found another tool that worked ( I think I just needed to run
>> wireshark as root), however this tool and tcpdump both do not give
>> what I want.  I am going through a VPN and it looks like all the
>> packets are encrypted.  The protocol for all packets is ESP.
>
> Philip's trick to redirect the traffic to local port 8080 via socat
> should let you see what your client is sending.
>
> But, a VPN could certainly be mucking with something...have you tried
> the HTTP/1.0 force yet?  You'd need serf 1.1.x which I don't think
> MacPorts has yet...

I do not think it is something like that because I have serf as my
default and it works fine with 1.7 client and was working fine with
trunk last week.  I assumed it was related to all of the XML parsing
Greg is working on.  I will try Philip's suggestion but assume I need
to read up on what he suggested so that I understand what I need to
do.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Philip Martin <ph...@wandisco.com>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:

> Philip's trick to redirect the traffic to local port 8080 via socat
> should let you see what your client is sending.

And receiving.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: Trunk checkout fails with serf but not neon

Posted by Blair Zajac <bl...@orcaware.com>.
On 05/16/2012 11:15 AM, Justin Erenkrantz wrote:
> On Wed, May 16, 2012 at 11:10 AM, Mark Phippard<ma...@gmail.com>  wrote:
>> I found another tool that worked ( I think I just needed to run
>> wireshark as root), however this tool and tcpdump both do not give
>> what I want.  I am going through a VPN and it looks like all the
>> packets are encrypted.  The protocol for all packets is ESP.
>
> Philip's trick to redirect the traffic to local port 8080 via socat
> should let you see what your client is sending.
>
> But, a VPN could certainly be mucking with something...have you tried
> the HTTP/1.0 force yet?  You'd need serf 1.1.x which I don't think
> MacPorts has yet...  -- justin

I'm the MacPorts serf maintainer.  I don't see anything newer than 1.0.3 
on http://code.google.com/p/serf/downloads/list, otherwise I probably 
would have updated it shortly after its release.

Blair

Re: Trunk checkout fails with serf but not neon

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, May 16, 2012 at 11:10 AM, Mark Phippard <ma...@gmail.com> wrote:
> I found another tool that worked ( I think I just needed to run
> wireshark as root), however this tool and tcpdump both do not give
> what I want.  I am going through a VPN and it looks like all the
> packets are encrypted.  The protocol for all packets is ESP.

Philip's trick to redirect the traffic to local port 8080 via socat
should let you see what your client is sending.

But, a VPN could certainly be mucking with something...have you tried
the HTTP/1.0 force yet?  You'd need serf 1.1.x which I don't think
MacPorts has yet...  -- justin

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 1:57 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Wed, May 16, 2012 at 10:55 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I am trying Wireshark but it says I do not have any interfaces it can
>> use.  I am on a Macbook Air so maybe it needs an Ethernet adapter.
>> Looking for other mac capture tools right now.
>
> As root, use:
>
> # tcpdump -w /tmp/mycapture.dump -i en0 -s 0 host cu121.cloud.sp.collab.net
>
> (This is assuming that en0 is your wireless adapter on your Mac.)

I found another tool that worked ( I think I just needed to run
wireshark as root), however this tool and tcpdump both do not give
what I want.  I am going through a VPN and it looks like all the
packets are encrypted.  The protocol for all packets is ESP.




-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, May 16, 2012 at 10:55 AM, Mark Phippard <ma...@gmail.com> wrote:
> I am trying Wireshark but it says I do not have any interfaces it can
> use.  I am on a Macbook Air so maybe it needs an Ethernet adapter.
> Looking for other mac capture tools right now.

As root, use:

# tcpdump -w /tmp/mycapture.dump -i en0 -s 0 host cu121.cloud.sp.collab.net

(This is assuming that en0 is your wireless adapter on your Mac.)

HTH.  -- justin

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 1:50 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Wed, May 16, 2012 at 8:45 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I cannot recreate this with the Apache repository, but with a local
>> 1.7.5 server and current trunk client I get this:
>
> I tried with a local 1.7.5 server and can't reproduce this.  It looks
> like the OPTIONS request is failing (note the 401 error
> code)...perhaps you have something interfering with your loopback
> interface?  I think we saw that some A/V scanners on Windows install
> bad packet filters.

I thought the 401 was because the server challenges for credentials?
The client is on a Mac.  I am using Serf from MacPorts which is 1.0.3.

Is there a way to use curl or some other tool to send the same OPTIONS
request and see what the response is?  When I do this, the response
does not have a body:

curl -u xxx:yyy --basic -X OPTIONS http://cu121.cloud.sp.collab.net/svn/desktop/

Assuming I need to send more stuff in my request to get back the
response a client would get.

I am trying Wireshark but it says I do not have any interfaces it can
use.  I am on a Macbook Air so maybe it needs an Ethernet adapter.
Looking for other mac capture tools right now.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, May 16, 2012 at 8:45 AM, Mark Phippard <ma...@gmail.com> wrote:
> I cannot recreate this with the Apache repository, but with a local
> 1.7.5 server and current trunk client I get this:

I tried with a local 1.7.5 server and can't reproduce this.  It looks
like the OPTIONS request is failing (note the 401 error
code)...perhaps you have something interfering with your loopback
interface?  I think we saw that some A/V scanners on Windows install
bad packet filters.

I'd suggest commenting out line 399 in libsvn_ra_serf/serf.c which
disables the HTTP/1.0 workaround and seeing how that works.  Note that
you'd also need to have serf 1.1.x to make it do anything.  -- justin

Index: subversion/libsvn_ra_serf/serf.c
===================================================================
--- subversion/libsvn_ra_serf/serf.c    (revision 1339277)
+++ subversion/libsvn_ra_serf/serf.c    (working copy)
@@ -396,7 +396,6 @@
   serf_sess->conns[0] = apr_pcalloc(serf_sess->pool,
                                     sizeof(*serf_sess->conns[0]));
   serf_sess->conns[0]->http10 = TRUE;  /* until we confirm HTTP/1.1  */
-  serf_sess->conns[0]->http10 = FALSE; /* ### don't change behavior yet  */
   serf_sess->conns[0]->bkt_alloc =
           serf_bucket_allocator_create(serf_sess->pool, NULL, NULL);
   serf_sess->conns[0]->session = serf_sess;

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 7:29 PM, Greg Stein <gs...@gmail.com> wrote:

> Excellent. And that told me what I needed to know. I believe it is now
> fixed in r1339425. Give it a whirl, please.

Fix confirmed.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Greg Stein <gs...@gmail.com>.
On Wed, May 16, 2012 at 6:34 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, May 16, 2012 at 5:55 PM, Greg Stein <gs...@gmail.com> wrote:
>> On Wed, May 16, 2012 at 11:45 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> I cannot recreate this with the Apache repository, but with a local
>>> 1.7.5 server and current trunk client I get this:
>>>
>>> $ svn co http://cu121.cloud.sp.collab.net/svn/desktop desktop
>>> --username=markphip --depth=immediates
>>> subversion/svn/checkout-cmd.c:168: (apr_err=130003)
>>> subversion/libsvn_client/checkout.c:103: (apr_err=130003)
>>> subversion/libsvn_client/ra.c:495: (apr_err=130003)
>>> subversion/libsvn_client/ra.c:362: (apr_err=130003)
>>> subversion/libsvn_ra/ra_loader.c:500: (apr_err=130003)
>>> svn: E130003: Unable to connect to a repository at URL
>>> 'http://cu121.cloud.sp.collab.net/svn/desktop'
>>> subversion/libsvn_ra_serf/util.c:780: (apr_err=130003)
>>> subversion/libsvn_ra_serf/util.c:737: (apr_err=130003)
>>> subversion/libsvn_ra_serf/util.c:1959: (apr_err=130003)
>>> subversion/libsvn_ra_serf/util.c:1940: (apr_err=130003)
>>> subversion/libsvn_ra_serf/util.c:2389: (apr_err=130003)
>>> svn: E130003: The OPTIONS response contains invalid XML (200 OK)
>>> Abort trap: 6
>>
>> That abort trap makes me think there is a forgotten error. I found a
>> likely cause and fixed that in r1339385. Could you build with that and
>> see if more error information is generated?
>
> I no longer get the Abort trap, but I do still get essentially the
> same error as before:
>
> Updating '.':
> subversion/svn/update-cmd.c:163: (apr_err=130003)
> subversion/libsvn_client/update.c:606: (apr_err=130003)
> subversion/libsvn_client/update.c:547: (apr_err=130003)
> subversion/libsvn_client/update.c:329: (apr_err=130003)
> subversion/libsvn_client/ra.c:362: (apr_err=130003)
> subversion/libsvn_ra/ra_loader.c:500: (apr_err=130003)
> svn: E130003: Unable to connect to a repository at URL
> 'http://cu121.cloud.sp.collab.net/svn/desktop'
> subversion/libsvn_ra_serf/util.c:780: (apr_err=130003)
> subversion/libsvn_ra_serf/util.c:737: (apr_err=130003)
> subversion/libsvn_ra_serf/util.c:1968: (apr_err=130003)
> subversion/libsvn_ra_serf/util.c:1949: (apr_err=130003)
> subversion/libsvn_ra_serf/util.c:2398: (apr_err=130003)
> svn: E130003: The OPTIONS response contains invalid XML (200 OK)
> subversion/libsvn_ra_serf/util.c:2324: (apr_err=130003)
> subversion/libsvn_ra_serf/xml.c:693: (apr_err=130003)
> svn: E130003: The response contains invalid XML

Excellent. And that told me what I needed to know. I believe it is now
fixed in r1339425. Give it a whirl, please.

Cheers,
-g

Re: Trunk checkout fails with serf but not neon

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 16, 2012 at 5:55 PM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, May 16, 2012 at 11:45 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I cannot recreate this with the Apache repository, but with a local
>> 1.7.5 server and current trunk client I get this:
>>
>> $ svn co http://cu121.cloud.sp.collab.net/svn/desktop desktop
>> --username=markphip --depth=immediates
>> subversion/svn/checkout-cmd.c:168: (apr_err=130003)
>> subversion/libsvn_client/checkout.c:103: (apr_err=130003)
>> subversion/libsvn_client/ra.c:495: (apr_err=130003)
>> subversion/libsvn_client/ra.c:362: (apr_err=130003)
>> subversion/libsvn_ra/ra_loader.c:500: (apr_err=130003)
>> svn: E130003: Unable to connect to a repository at URL
>> 'http://cu121.cloud.sp.collab.net/svn/desktop'
>> subversion/libsvn_ra_serf/util.c:780: (apr_err=130003)
>> subversion/libsvn_ra_serf/util.c:737: (apr_err=130003)
>> subversion/libsvn_ra_serf/util.c:1959: (apr_err=130003)
>> subversion/libsvn_ra_serf/util.c:1940: (apr_err=130003)
>> subversion/libsvn_ra_serf/util.c:2389: (apr_err=130003)
>> svn: E130003: The OPTIONS response contains invalid XML (200 OK)
>> Abort trap: 6
>
> That abort trap makes me think there is a forgotten error. I found a
> likely cause and fixed that in r1339385. Could you build with that and
> see if more error information is generated?

I no longer get the Abort trap, but I do still get essentially the
same error as before:

Updating '.':
subversion/svn/update-cmd.c:163: (apr_err=130003)
subversion/libsvn_client/update.c:606: (apr_err=130003)
subversion/libsvn_client/update.c:547: (apr_err=130003)
subversion/libsvn_client/update.c:329: (apr_err=130003)
subversion/libsvn_client/ra.c:362: (apr_err=130003)
subversion/libsvn_ra/ra_loader.c:500: (apr_err=130003)
svn: E130003: Unable to connect to a repository at URL
'http://cu121.cloud.sp.collab.net/svn/desktop'
subversion/libsvn_ra_serf/util.c:780: (apr_err=130003)
subversion/libsvn_ra_serf/util.c:737: (apr_err=130003)
subversion/libsvn_ra_serf/util.c:1968: (apr_err=130003)
subversion/libsvn_ra_serf/util.c:1949: (apr_err=130003)
subversion/libsvn_ra_serf/util.c:2398: (apr_err=130003)
svn: E130003: The OPTIONS response contains invalid XML (200 OK)
subversion/libsvn_ra_serf/util.c:2324: (apr_err=130003)
subversion/libsvn_ra_serf/xml.c:693: (apr_err=130003)
svn: E130003: The response contains invalid XML




-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

Posted by Greg Stein <gs...@gmail.com>.
On May 16, 2012 6:04 PM, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>
> On Thu, May 17, 2012 at 1:55 AM, Greg Stein <gs...@gmail.com> wrote:
> > On Wed, May 16, 2012 at 11:45 AM, Mark Phippard <ma...@gmail.com>
wrote:
> >> I cannot recreate this with the Apache repository, but with a local
> >> 1.7.5 server and current trunk client I get this:
> >>
> >> $ svn co http://cu121.cloud.sp.collab.net/svn/desktop desktop
> >> --username=markphip --depth=immediates
> >> subversion/svn/checkout-cmd.c:168: (apr_err=130003)
> >> subversion/libsvn_client/checkout.c:103: (apr_err=130003)
> >> subversion/libsvn_client/ra.c:495: (apr_err=130003)
> >> subversion/libsvn_client/ra.c:362: (apr_err=130003)
> >> subversion/libsvn_ra/ra_loader.c:500: (apr_err=130003)
> >> svn: E130003: Unable to connect to a repository at URL
> >> 'http://cu121.cloud.sp.collab.net/svn/desktop'
> >> subversion/libsvn_ra_serf/util.c:780: (apr_err=130003)
> >> subversion/libsvn_ra_serf/util.c:737: (apr_err=130003)
> >> subversion/libsvn_ra_serf/util.c:1959: (apr_err=130003)
> >> subversion/libsvn_ra_serf/util.c:1940: (apr_err=130003)
> >> subversion/libsvn_ra_serf/util.c:2389: (apr_err=130003)
> >> svn: E130003: The OPTIONS response contains invalid XML (200 OK)
> >> Abort trap: 6
> >
> > That abort trap makes me think there is a forgotten error. I found a
> > likely cause and fixed that in r1339385. Could you build with that and
> > see if more error information is generated?
> >
> I think the real problem that serf_bucket_read() returns APR_EAGAIN
> and zero data. And then this zero buffer passed to expat.

svn_ra_serf__handle_xml_parser() also passes such bucket return values into
Expat.

Cheers,
-g

Re: Trunk checkout fails with serf but not neon

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, May 17, 2012 at 1:55 AM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, May 16, 2012 at 11:45 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I cannot recreate this with the Apache repository, but with a local
>> 1.7.5 server and current trunk client I get this:
>>
>> $ svn co http://cu121.cloud.sp.collab.net/svn/desktop desktop
>> --username=markphip --depth=immediates
>> subversion/svn/checkout-cmd.c:168: (apr_err=130003)
>> subversion/libsvn_client/checkout.c:103: (apr_err=130003)
>> subversion/libsvn_client/ra.c:495: (apr_err=130003)
>> subversion/libsvn_client/ra.c:362: (apr_err=130003)
>> subversion/libsvn_ra/ra_loader.c:500: (apr_err=130003)
>> svn: E130003: Unable to connect to a repository at URL
>> 'http://cu121.cloud.sp.collab.net/svn/desktop'
>> subversion/libsvn_ra_serf/util.c:780: (apr_err=130003)
>> subversion/libsvn_ra_serf/util.c:737: (apr_err=130003)
>> subversion/libsvn_ra_serf/util.c:1959: (apr_err=130003)
>> subversion/libsvn_ra_serf/util.c:1940: (apr_err=130003)
>> subversion/libsvn_ra_serf/util.c:2389: (apr_err=130003)
>> svn: E130003: The OPTIONS response contains invalid XML (200 OK)
>> Abort trap: 6
>
> That abort trap makes me think there is a forgotten error. I found a
> likely cause and fixed that in r1339385. Could you build with that and
> see if more error information is generated?
>
I think the real problem that serf_bucket_read() returns APR_EAGAIN
and zero data. And then this zero buffer passed to expat.


-- 
Ivan Zhakov

Re: Trunk checkout fails with serf but not neon

Posted by Greg Stein <gs...@gmail.com>.
On Wed, May 16, 2012 at 11:45 AM, Mark Phippard <ma...@gmail.com> wrote:
> I cannot recreate this with the Apache repository, but with a local
> 1.7.5 server and current trunk client I get this:
>
> $ svn co http://cu121.cloud.sp.collab.net/svn/desktop desktop
> --username=markphip --depth=immediates
> subversion/svn/checkout-cmd.c:168: (apr_err=130003)
> subversion/libsvn_client/checkout.c:103: (apr_err=130003)
> subversion/libsvn_client/ra.c:495: (apr_err=130003)
> subversion/libsvn_client/ra.c:362: (apr_err=130003)
> subversion/libsvn_ra/ra_loader.c:500: (apr_err=130003)
> svn: E130003: Unable to connect to a repository at URL
> 'http://cu121.cloud.sp.collab.net/svn/desktop'
> subversion/libsvn_ra_serf/util.c:780: (apr_err=130003)
> subversion/libsvn_ra_serf/util.c:737: (apr_err=130003)
> subversion/libsvn_ra_serf/util.c:1959: (apr_err=130003)
> subversion/libsvn_ra_serf/util.c:1940: (apr_err=130003)
> subversion/libsvn_ra_serf/util.c:2389: (apr_err=130003)
> svn: E130003: The OPTIONS response contains invalid XML (200 OK)
> Abort trap: 6

That abort trap makes me think there is a forgotten error. I found a
likely cause and fixed that in r1339385. Could you build with that and
see if more error information is generated?

>...

Thx,
-g