You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2010/02/05 10:29:34 UTC
Old repository
Hi Michael,
Can you make opening an ra session (like this):
$ svn export http://svn.collab.net/repos/svn/trunk/COMMITTERS
svn: OPTIONS of 'http://svn.collab.net/repos/svn/trunk/COMMITTERS': 200 OK
(http://svn.collab.net)
return some other output?
Presumably, it should be possible to reroute the OPTIONS request to a cgi
script that returns a different error?
I remember that I once changed the description (The "OK" part) to a
different string when I send a different error code.
Bert Huijben
Re: ra_serf pool cleanup SEGV
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Julian Foad <ju...@btopenworld.com> writes:
>
>> which is better, but a trunk build using Serf just says:
>>
>>> svn: XML parsing failed: (405 Method Not Allowed)
>
> It's worse than that. My full valgrind build gives a SEGV, but only
> after a whole slew of valgrind warnings like:
And with pool debugging enabled in serf for a bit more detail:
==14307== Invalid read of size 4
==14307== at 0x9AEAFAF: serf_bucket_mem_free (allocator.c:223)
==14307== by 0x9AE9B83: serf_response_destroy_and_data (response_buckets.c:86)
==14307== by 0x9AE5F37: cancel_request (context.c:437)
==14307== by 0x9AE774B: serf_request_cancel (context.c:1384)
==14307== by 0x9AE736A: serf_connection_close (context.c:1249)
==14307== by 0x9AE59BC: clean_conn (context.c:184)
==14307== by 0x5E1329A: run_cleanups (apr_pools.c:2071)
==14307== by 0x5E12398: pool_clear_debug (apr_pools.c:1409)
==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==14307== Address 0xa8b4688 is 32 bytes inside a block of size 64 free'd
==14307== at 0x4C2130F: free (vg_replace_malloc.c:323)
==14307== by 0x5E12469: pool_clear_debug (apr_pools.c:1432)
==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==14307== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==14307== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==14307== by 0x5E1266D: apr_pool_destroy_debug (apr_pools.c:1536)
==14307== by 0x414B27: main (main.c:2262)
There is no Subversion code beyond main. Is this a serf bug, rather
than a Subversion bug? I'm using serf 0.3.0.
--
Philip
ra_serf pool cleanup SEGV
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@btopenworld.com> writes:
> which is better, but a trunk build using Serf just says:
>
>> svn: XML parsing failed: (405 Method Not Allowed)
It's worse than that. My full valgrind build gives a SEGV, but only
after a whole slew of valgrind warnings like:
$ valgrind -q subversion/svn/.libs/lt-svn ls http://svn.collab.net/repos/svn/trunk/COMMITTERS
svn: XML parsing failed: (405 Method Not Allowed)
==3696== Invalid read of size 4
==3696== at 0x9AEAF2A: serf_bucket_mem_free (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE9AF3: serf_response_destroy_and_data (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE5EC0: cancel_request (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE76BD: serf_request_cancel (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE72DC: serf_connection_close (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE594C: clean_conn (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x5E1329A: run_cleanups (apr_pools.c:2071)
==3696== by 0x5E12398: pool_clear_debug (apr_pools.c:1409)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== Address 0xa8b4688 is 32 bytes inside a block of size 64 free'd
==3696== at 0x4C2130F: free (vg_replace_malloc.c:323)
==3696== by 0x5E12469: pool_clear_debug (apr_pools.c:1432)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1266D: apr_pool_destroy_debug (apr_pools.c:1536)
==3696== by 0x414B27: main (main.c:2262)
==3696==
==3696== Invalid write of size 4
==3696== at 0x9AEAF34: serf_bucket_mem_free (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE9AF3: serf_response_destroy_and_data (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE5EC0: cancel_request (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE76BD: serf_request_cancel (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE72DC: serf_connection_close (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x9AE594C: clean_conn (in /usr/local/serf/lib/libserf-0.so.0.0.0)
==3696== by 0x5E1329A: run_cleanups (apr_pools.c:2071)
==3696== by 0x5E12398: pool_clear_debug (apr_pools.c:1409)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== Address 0xa8b4688 is 32 bytes inside a block of size 64 free'd
==3696== at 0x4C2130F: free (vg_replace_malloc.c:323)
==3696== by 0x5E12469: pool_clear_debug (apr_pools.c:1432)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1237E: pool_clear_debug (apr_pools.c:1406)
==3696== by 0x5E12599: pool_destroy_debug (apr_pools.c:1494)
==3696== by 0x5E1266D: apr_pool_destroy_debug (apr_pools.c:1536)
==3696== by 0x414B27: main (main.c:2262)
--
Philip
Re: Old repository
Posted by Julian Foad <ju...@btopenworld.com>.
Lieven Govaerts wrote:
> On Fri, Feb 5, 2010 at 11:29 AM, Bert Huijben <be...@qqmail.nl> wrote:
> > Hi Michael,
> >
> > Can you make opening an ra session (like this):
> >
> > $ svn export http://svn.collab.net/repos/svn/trunk/COMMITTERS
> >
> > svn: OPTIONS of 'http://svn.collab.net/repos/svn/trunk/COMMITTERS': 200 OK
> > (http://svn.collab.net)
> >
> > return some other output?
> >
> > Presumably, it should be possible to reroute the OPTIONS request to a cgi
> > script that returns a different error?
>
> Shouldn't we fix svn to give a better error message in this situation instead?
I think Bert's request is a good one, for the sake of users of released
clients, if it's not too much trouble for Mike to do.
But we should fix Subversion as well...
> In fact, is't that what Julian's patch is about:
> http://svn.haxx.se/dev/archive-2010-01/0211.shtml
Yes.
Note that a trunk build using Neon now says:
> svn: Unable to connect to a repository at URL
> 'http://svn.collab.net/repos/svn/trunk/COMMITTERS'
> svn: The OPTIONS request returned invalid XML in the response: XML
> parse error at line 1: Extra content at the end of the document
> (http://svn.collab.net/repos/svn/trunk/COMMITTERS)
which is better, but a trunk build using Serf just says:
> svn: XML parsing failed: (405 Method Not Allowed)
- Julian
RE: Old repository
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: lieven.govaerts@gmail.com [mailto:lieven.govaerts@gmail.com] On
> Behalf Of Lieven Govaerts
> Sent: vrijdag 5 februari 2010 11:46
> To: Bert Huijben
> Cc: C. Michael Pilato; dev@subversion.apache.org
> Subject: Re: Old repository
>
> On Fri, Feb 5, 2010 at 11:29 AM, Bert Huijben <be...@qqmail.nl> wrote:
> > Hi Michael,
> >
> >
> >
> > Can you make opening an ra session (like this):
> >
> >
> > $ svn export http://svn.collab.net/repos/svn/trunk/COMMITTERS
> >
> > svn: OPTIONS of 'http://svn.collab.net/repos/svn/trunk/COMMITTERS':
> 200 OK
> > (http://svn.collab.net)
> >
> > return some other output?
> >
> >
> > Presumably, it should be possible to reroute the OPTIONS request to a
cgi
> > script that returns a different error?
>
> Shouldn't we fix svn to give a better error message in this situation
instead?
>
> In fact, is't that what Julian's patch is about:
> http://svn.haxx.se/dev/archive-2010-01/0211.shtml
I would have suggested "404 Repository integrated with ASF. Please look at
http://svn.apache.org/repos/asf/subversion"
With that, you would have the same information as the site, but then via
your subversion client.
Bert
Re: Old repository
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Fri, Feb 5, 2010 at 11:29 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Hi Michael,
>
>
>
> Can you make opening an ra session (like this):
>
>
> $ svn export http://svn.collab.net/repos/svn/trunk/COMMITTERS
>
> svn: OPTIONS of 'http://svn.collab.net/repos/svn/trunk/COMMITTERS': 200 OK
> (http://svn.collab.net)
>
> return some other output?
>
>
> Presumably, it should be possible to reroute the OPTIONS request to a cgi
> script that returns a different error?
Shouldn't we fix svn to give a better error message in this situation instead?
In fact, is't that what Julian's patch is about:
http://svn.haxx.se/dev/archive-2010-01/0211.shtml
[..]
Lieven
Re: Old repository
Posted by Роман Донченко <DX...@yandex.ru>.
C. Michael Pilato <cm...@collab.net> писал в своём письме Fri, 05 Feb
2010 19:33:09 +0300:
> Bert Huijben wrote:
>> Can you make opening an ra session (like this):
>>
>> $ svn export http://svn.collab.net/repos/svn/trunk/COMMITTERS
>>
>> svn: OPTIONS of 'http://svn.collab.net/repos/svn/trunk/COMMITTERS': 200
>> OK (http://svn.collab.net)
>>
>> return some other output?
>>
>> Presumably, it should be possible to reroute the OPTIONS request to a
>> cgi script that returns a different error?
>
> I honestly don't know how to do what you're asking. CGI scripts only run
> (as far as I know) when a GET or POST request comes in.
>
> I just now added to the configury on svn.collab.net logic to bounce every
> non-GET request aimed at that old repository URL as a 403 Access Denied.
Should've used 410 Gone. 8=]
Roman.
Re: Old repository
Posted by "C. Michael Pilato" <cm...@collab.net>.
Bert Huijben wrote:
> Can you make opening an ra session (like this):
>
> $ svn export http://svn.collab.net/repos/svn/trunk/COMMITTERS
>
> svn: OPTIONS of 'http://svn.collab.net/repos/svn/trunk/COMMITTERS': 200
> OK (http://svn.collab.net)
>
> return some other output?
>
> Presumably, it should be possible to reroute the OPTIONS request to a
> cgi script that returns a different error?
I honestly don't know how to do what you're asking. CGI scripts only run
(as far as I know) when a GET or POST request comes in.
I just now added to the configury on svn.collab.net logic to bounce every
non-GET request aimed at that old repository URL as a 403 Access Denied. I
tried adding a custom ErrorDocument handler for 403's in that location, but
either Apache didn't use it or Subversion didn't display it -- either way my
custom text didn't show in the 'svn' client output.
So anyway, now if you hit one of the old repos URLs with a web browser (a
GET request), you see the redirection CGI script I already had in place.
If you hit it with a Subversion client (which will try an OPTIONS request
first), you see:
svn: Server sent unexpected return value (403 Forbidden) in response
to OPTIONS request for 'https://svn.collab.net/repos/svn'
That might be the best I can do for now.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand