You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2005/08/11 19:16:40 UTC
1.2.2 is not ready [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Mark Phippard wrote:
>Branko Čibej <br...@xbc.nu> wrote on 08/11/2005 02:55:20 PM:
>
>
>>So it seems that the bug is fixed in 1.2.2, too.
>>
>>
>
>That is good, but is there any way you could just try Stefan's test
>against tigris.org to be sure? I think he reduced it something pretty
>simple.
>
>svn co http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/API test
>cd test
>svn lock Doxyfile
>
>Maybe Stefan just did something wrong in his build, or his test picked up
>the old executable? It can't hurt to do the exact same test. The URL he
>gave just has two files in it.
>
>
Sure, I'll try this...
[5 minutes later]
Well, well, well. All three, 1.2.0, 1.2.2 and trunk fail here. And the
server returns a _different_ error code than in my local tests. Here's
the result from trunk:
$ ../../repos/svn-trunk/Release/subversion/clients/cmdline/svn.exe lock Doxyfile
Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM Repository
Password for 'brane': *********
Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM Repository
Password for 'brane': *********
Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM Repository
Username: brane
Password for 'brane': *********
Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM Repository
Username: brane
Password for 'brane': *********
NEON_ERR 1 401 Authorization Required
SVN_ERR 175002 Lock request failed: 401 Authorization Required (http://tortoises
vn.tigris.org)
Trunk then crashes. 1.2.0 doesn't, neither does 1.2.2, it seems.
The only difference between my local test and the remote tigris.org test
is that a) my server is Windows, and b) I use httpd-2.0.54, while
tigris.org presumably doesn't. So it looks like a combination of mod_dav
bug and svn client bug.
I think this is serious enough to hold up the 1.2.2 release, espeially
as I see new warnings in the Windows build of the Python bindings, too:
subversion\bindings\swig\python\core.c(2938) : warning C4047: '=' : 'struct _object *' differs in levels of indirection from 'struct apr_array_header_t ** '
subversion\bindings\swig\python\core.c(2941) : warning C4047: '=' : 'struct _object *' differs in levels of indirection from 'struct apr_array_header_t ** '
subversion\bindings\swig\python\core.c(2944) : warning C4047: '=' : 'struct _object *' differs in levels of indirection from 'struct apr_array_header_t ** '
subversion\bindings\swig\python\core.c(6164) : warning C4013: 'svn_utf_initialize' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6212) : warning C4013: 'svn_utf_stringbuf_to_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6287) : warning C4013: 'svn_utf_string_to_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6345) : warning C4013: 'svn_utf_cstring_to_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6405) : warning C4013: 'svn_utf_cstring_to_utf8_ex' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6476) : warning C4013: 'svn_utf_stringbuf_from_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6551) : warning C4013: 'svn_utf_string_from_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6609) : warning C4013: 'svn_utf_cstring_from_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6669) : warning C4013: 'svn_utf_cstring_from_utf8_ex' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6724) : warning C4013: 'svn_utf_cstring_from_utf8_fuzzy' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6770) : warning C4013: 'svn_utf_cstring_from_utf8_stringbuf' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6843) : warning C4013: 'svn_utf_cstring_from_utf8_string' undefined; assuming extern returning int
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 11 Aug 2005, Philip Martin wrote:
> Branko ?ibej <br...@xbc.nu> writes:
...
> tigris.org claims to be running httpd 2.0.50 with mod_dav_svn 1.1.1,
> my local server is Debian's httpd 2.0.54-4 with mod_dav_svn 1.1.4-2.
It is what it claims to be, with a small patch to httpd's mod_headers,
and some bug fix patches to subversion (from 1.1.2+).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@xbc.nu> writes:
> Philip Martin wrote:
>>
>>I don't get a crash when I try to reproduce the problem against a
>>local 1.1.4 server.
>>
> I didn't get a crash when I tested against a local server, either, but
> then I probably have a newer httpd than the one that's running on
> tigris.org. That could make a difference.
I suppose it could be mod_dav_svn or httpd.
tigris.org claims to be running httpd 2.0.50 with mod_dav_svn 1.1.1,
my local server is Debian's httpd 2.0.54-4 with mod_dav_svn 1.1.4-2.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>
>>With write access to the tsvn repo, I can confirm this -- both 1.2.2
>>and trunk.
>>
>>Stefan, thanks, you can revoke my write access now.
>>
>>
>
>I appear to have (write?) access, and yes I also get a crash.
>
>I don't get a crash when I try to reproduce the problem against a
>local 1.1.4 server.
>
>
I didn't get a crash when I tested against a local server, either, but
then I probably have a newer httpd than the one that's running on
tigris.org. That could make a difference.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] storing auth after auth failure
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>
>>>- if (! state)
>>>+ if (! state || state->table->providers->nelts == state->provider_idx)
>>> return SVN_NO_ERROR;
>>>
>>>
>>>
>>>
>>I think we should go ahead and store the auth info anyway, as I do in
>>my patch.
>>
>>
>
>Hmm, as far as I can see your patch doesn't store the auth info
>either. I don't mind which patch you commit as I think they have the
>same effect :)
>
>
Your patch makes save_creds bail out if the initial provider index is
out of range. My patch just skips the initial creds save with the
"default" provider, but still goes through the loop -- which,
presumably, will save the authn info.
Maybe we can toss a coin to decide which patch goes in. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] storing auth after auth failure
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@xbc.nu> writes:
>>- if (! state)
>>+ if (! state || state->table->providers->nelts == state->provider_idx)
>> return SVN_NO_ERROR;
>>
>>
> I think we should go ahead and store the auth info anyway, as I do in
> my patch.
Hmm, as far as I can see your patch doesn't store the auth info
either. I don't mind which patch you commit as I think they have the
same effect :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] storing auth after auth failure
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Philip Martin <ph...@codematters.co.uk> writes:
>
>
>
>>Branko Čibej <br...@xbc.nu> writes:
>>
>>
>>
>>>With write access to the tsvn repo, I can confirm this -- both 1.2.2
>>>and trunk.
>>>
>>>Stefan, thanks, you can revoke my write access now.
>>>
>>>
>>I appear to have (write?) access, and yes I also get a crash.
>>
>>
>
>I stepped through trunk client aginst tsvn server:
>
>
[...]
Well! Beat me by 8 minutes. :)
>- if (! state)
>+ if (! state || state->table->providers->nelts == state->provider_idx)
> return SVN_NO_ERROR;
>
>
I think we should go ahead and store the auth info anyway, as I do in my
patch. What we're seeing here is a server bug that we can't really
detect and work around in the client.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] storing auth after auth failure
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Branko Čibej <br...@xbc.nu> writes:
>
>> With write access to the tsvn repo, I can confirm this -- both 1.2.2
>> and trunk.
>>
>> Stefan, thanks, you can revoke my write access now.
>
> I appear to have (write?) access, and yes I also get a crash.
I stepped through trunk client aginst tsvn server:
a) the client calls svn_ra_dav__lock
b) svn_ra_dav__lock calls shim_svn_ra_dav__lock
c) shim_svn_ra_dav__lock calls svn_ra_dav__get_baseline_info which
prompts for auth and succeeds
d) shim_svn_ra_dav__lock calls ne_lock which prompts for auth three
times, the first prompt is for a password, the second and third
prompts are for both username and password.
e) the ne_lock call fails and returns 1 (or NE_ERROR)
f) shim_svn_ra_dav__lock calls svn_ra_dav__convert_error which
creates an SVN_ERR_RA_DAV_REQUEST_FAILED error
g) shim_svn_ra_dav__lock returns to svn_ra_dav__lock
h) svn_ra_dav__lock
calls
svn_ra_dav__maybe_store_auth_info_after_result
which calls
svn_ra_dav__maybe_store_auth_info
which calls
svn_auth_save_credentials
i) svn_auth_save_credentials retieves a NULL provider and then SEGVs
accessing provider->vtable->save_credentials
I don't really understand the auth stuff, but I think the fact that
(d) prompts three times indicates that the auth is failing. It seems
that there are two things that could be considered bugs:
1) the ra_dav code does not recognise the error as an auth failure
because ne_lock returns NE_ERROR rather than NE_AUTH (I'm using
neon 0.24.7)
2) the auth code crashes when asked to store auth after an auth
failure
I don't know whether, or how, we should fix (1) but I can fix (2)
using this:
Index: subversion/libsvn_subr/auth.c
===================================================================
--- subversion/libsvn_subr/auth.c (revision 15679)
+++ subversion/libsvn_subr/auth.c (working copy)
@@ -297,7 +297,7 @@
svn_auth_baton_t *auth_baton;
void *creds;
- if (! state)
+ if (! state || state->table->providers->nelts == state->provider_idx)
return SVN_NO_ERROR;
auth_baton = state->auth_baton;
and then the client gives me
$ svn lock wc/Doxyfile --username guest
...
svn: Lock request failed: 401 Authorization Required (http://tortoisesvn.tigris.org)
I don't know whether it's sensible to silently do nothing when storing
auth after an auth failure, perhaps an error should be returned.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Mark Phippard <Ma...@softlanding.com>.
SteveKing <st...@gmx.ch> wrote on 08/11/2005 04:36:27 PM:
> Mark Phippard wrote:
>
> >>I appear to have (write?) access, and yes I also get a crash.
> >>
> >>I don't get a crash when I try to reproduce the problem against a
> >>local 1.1.4 server.
> >
> >
> > I do not think write access has anything to do with it. I used
> > credentials of guest/guest against TSVN repos and I got the crash.
>
> Maybe not write access, but you must have your auth data cached on disk
> to make it crash.
Correct. When I did the svn co I gave it guest/guest for credentials and
let it cache it.
As you are well aware, the tigris.org repositories require credentials
even for reading.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by SteveKing <st...@gmx.ch>.
Mark Phippard wrote:
>>I appear to have (write?) access, and yes I also get a crash.
>>
>>I don't get a crash when I try to reproduce the problem against a
>>local 1.1.4 server.
>
>
> I do not think write access has anything to do with it. I used
> credentials of guest/guest against TSVN repos and I got the crash.
Maybe not write access, but you must have your auth data cached on disk
to make it crash.
But since other people now can reproduce the crash, I don't think that
my build is broken anymore ;)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Mark Phippard <Ma...@softlanding.com>.
Philip Martin <ph...@codematters.co.uk> wrote on 08/11/2005 04:20:42 PM:
> Branko Čibej <br...@xbc.nu> writes:
>
> > With write access to the tsvn repo, I can confirm this -- both 1.2.2
> > and trunk.
> >
> > Stefan, thanks, you can revoke my write access now.
>
> I appear to have (write?) access, and yes I also get a crash.
>
> I don't get a crash when I try to reproduce the problem against a
> local 1.1.4 server.
I do not think write access has anything to do with it. I used
credentials of guest/guest against TSVN repos and I got the crash.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@xbc.nu> writes:
> With write access to the tsvn repo, I can confirm this -- both 1.2.2
> and trunk.
>
> Stefan, thanks, you can revoke my write access now.
I appear to have (write?) access, and yes I also get a crash.
I don't get a crash when I try to reproduce the problem against a
local 1.1.4 server.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by Branko Čibej <br...@xbc.nu>.
SteveKing wrote:
> Mark Phippard wrote:
>
>> OK, I just built 1.2.2 from the zip and did this test. I get the
>> same thing as you, except svn crashes at the end when I do it.
>
>
> It also crashes for me, but only if I have my auth data already
> stored. If I clean the auth cache on my harddrive, then I just get an
> 'authorization failed' without a crash.
> And it also only crashes if I *don't* give --username and/or
> --password on the commandline.
>
> I've sent Branko my auth folder via PM (hope he doesn't try to crack
> the password :) ) to try. But I'm not even sure that will help: the
> auth data is encrypted now and I think windows won't let him decrypt
> it (haven't thought of that before I sent him the zip file).
>
>> I thought I would try svn st -u after to see if that had the
>> problem. It seems to work OK.
>
>
> I've tested the 'svn st -u' with the 1.2.2 and that works. Ben has
> fixed that really good.
>
> I've just built svn from HEAD, and it too crashes.
>
> So I'll try to get together what we found out so far:
>
> $ svn lock file
> with client 1.2.1 up to 1.2.2 (and HEAD) can crash if
> - the lock is done to a http server 1.1.1 (like tigris.org)
> - the user has commit access to the repository
> - the user has the auth data cached on disk
> - no --username and/or --password is given on the command line
With write access to the tsvn repo, I can confirm this -- both 1.2.2 and
trunk.
Stefan, thanks, you can revoke my write access now.
Anyway, I think doesn't make sense to ship 1.2.2 with such a bug.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by SteveKing <st...@gmx.ch>.
Mark Phippard wrote:
> OK, I just built 1.2.2 from the zip and did this test. I get the same
> thing as you, except svn crashes at the end when I do it.
It also crashes for me, but only if I have my auth data already stored.
If I clean the auth cache on my harddrive, then I just get an
'authorization failed' without a crash.
And it also only crashes if I *don't* give --username and/or --password
on the commandline.
I've sent Branko my auth folder via PM (hope he doesn't try to crack the
password :) ) to try. But I'm not even sure that will help: the auth
data is encrypted now and I think windows won't let him decrypt it
(haven't thought of that before I sent him the zip file).
> I thought I would try svn st -u after to see if that had the problem. It
> seems to work OK.
I've tested the 'svn st -u' with the 1.2.2 and that works. Ben has fixed
that really good.
I've just built svn from HEAD, and it too crashes.
So I'll try to get together what we found out so far:
$ svn lock file
with client 1.2.1 up to 1.2.2 (and HEAD) can crash if
- the lock is done to a http server 1.1.1 (like tigris.org)
- the user has commit access to the repository
- the user has the auth data cached on disk
- no --username and/or --password is given on the command line
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by Mark Phippard <Ma...@softlanding.com>.
Branko Čibej <br...@xbc.nu> wrote on 08/11/2005 03:16:40 PM:
> Well, well, well. All three, 1.2.0, 1.2.2 and trunk fail here. And the
> server returns a _different_ error code than in my local tests. Here's
> the result from trunk:
>
> $ ../../repos/svn-trunk/Release/subversion/clients/cmdline/svn.exe lock
Doxyfile
> Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM
Repository
> Password for 'brane': *********
> Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM
Repository
> Password for 'brane': *********
> Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM
Repository
> Username: brane
> Password for 'brane': *********
> Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM
Repository
> Username: brane
> Password for 'brane': *********
> NEON_ERR 1 401 Authorization Required
> SVN_ERR 175002 Lock request failed: 401 Authorization Required
(http://tortoises
> vn.tigris.org)
>
>
> Trunk then crashes. 1.2.0 doesn't, neither does 1.2.2, it seems.
OK, I just built 1.2.2 from the zip and did this test. I get the same
thing as you, except svn crashes at the end when I do it.
I thought I would try svn st -u after to see if that had the problem. It
seems to work OK.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org