You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2006/11/13 14:31:54 UTC
crash in 1.4.2 and https
Hi,
It's only the first day of the week after I released TortoiseSVN 1.4.1,
and my inbox already fills up with crashreport mails :(
Fortunately, I got a good stacktrace from those (until now, all 14
reports I got are from the same problem). It seems there's a problem
either in the Subversion library or in neon 0.26.2. I hope you guys can
help me figure this out.
The crash happens with any command accessing a repository via https, but
as I found out not all the time. I'm still in contact with one of the
users who runs into this problem, so I'll keep posting more information
as I get them. BTW: the crash also happens with the command line client
version 1.4.2.
The crash happens because in svn_auth_next_credentials, the second
function parameter is NULL, and the third line after the function start
the line
provider_set_t *table = state->table;
then accesses the NULL param 'state'.
Here's the stacktrace:
!svn_auth_next_credentials(void * * credentials=0x01bea804,
svn_auth_iterstate_t * state=0x00000000, apr_pool_t * pool=0x00d620d8)
Line 243
request_auth(void * userdata=0x00d621d0, const char * realm=0x01c11e90,
int attempt=2, char * username=0x00d67404, char * password=0x01bea82c)
Line 110 + 0x11 bytes
!get_credentials(auth_session * sess=0x00000000, int attempt=2,
auth_challenge * chall=0x00000000, char * pwbuf=0x00000000) Line 327 +
0x1d bytes
!basic_challenge(auth_session * sess=0x00d673f0, int attempt=2,
auth_challenge * parms=0x01c11e30) Line 346 + 0x1b bytes
!auth_challenge(auth_session * sess=0x00d673f0, int attempt=2, const
char * value=0x00000000) Line 1103 + 0xe bytes
!ah_post_send(ne_request_s * req=0x01bf66b8, void * cookie=0x01c11dc8,
const ne_status * status=0x01bf87bc) Line 1215 + 0x12 bytes
!ne_end_request(ne_request_s * req=0x01bf66b8) Line 1342 + 0x10 bytes
!ne_request_dispatch(ne_request_s * req=0x01bf66b8) Line 1401 + 0xa bytes
!parsed_request(ne_session_s * sess=0x00d7c698, const char *
method=0x00604c18, const char * url=0x00d62298, const char *
body=0x00000000, apr_file_t * body_file=0x00000000, void
(ne_xml_parser_s *, void *)* set_parser=0x00543f40, const
svn_ra_dav__xml_elm_t * elements=0x006064d0, int use_neon_shim=1, int
(void *, int, int)* validate_compat_cb=0x005439d0, int (void *, const
svn_ra_dav__xml_elm_t *, const char * *)* startelm_compat_cb=0x00543b50,
int (void *, const svn_ra_dav__xml_elm_t *, const char *)*
endelm_compat_cb=0x00543d30, int (void *, int, const char *, const char
*, const char * *)* startelm_cb=0x00000000, int (void *, int, const char
*, unsigned int)* cdata_cb=0x00000000, int (void *, int, const char *,
const char *)* endelm_cb=0x00000000, void * baton=0x01beaaa8, apr_hash_t
* extra_headers=0x00d622b0, int * status_code=0x00000000, int
spool_response=0, apr_pool_t * pool=0x00d620d8) Line 715 + 0x6 bytes
!svn_ra_dav__parsed_request_compat(ne_session_s * sess=0x00d7c698, const
char * method=0x00604c18, const char * url=0x00d62298, const char *
body=0x00e13f80, apr_file_t * body_file=0x00000000, void
(ne_xml_parser_s *, void *)* set_parser=0x00543f40, const
svn_ra_dav__xml_elm_t * elements=0x006064d0, int (void *, int, int)*
validate_cb=0x005439d0, int (void *, const svn_ra_dav__xml_elm_t *,
const char * *)* startelm_cb=0x00543b50, int (void *, const
svn_ra_dav__xml_elm_t *, const char *)* endelm_cb=0x00543d30, void *
baton=0x01beaaa8, apr_hash_t * extra_headers=0x00d622b0, int *
status_code=0x00000000, int spool_response=0, apr_pool_t *
pool=0x00d620d8) Line 880 + 0x57 bytes
!svn_ra_dav__get_props(apr_hash_t * * results=0x01beaaf4, ne_session_s *
sess=0x00d7c698, const char * url=0x00d62298, int depth=0, const char *
label=0x00000000, const ne_propname * which_props=0x00606390, apr_pool_t
* pool=0x00d622b0) Line 539
!svn_ra_dav__get_props_resource(svn_ra_dav_resource_t * *
rsrc=0x01beab80, ne_session_s * sess=0x00d7c698, const char *
url=0x00d62270, const char * label=0x00000000, const ne_propname *
which_props=0x00606390, apr_pool_t * pool=0x00d620d8) Line 559 + 0x1d bytes
!svn_ra_dav__get_starting_props(svn_ra_dav_resource_t * *
rsrc=0x01beab80, ne_session_s * sess=0x00d7c698, const char *
url=0x00d62270, const char * label=0x00000000, apr_pool_t *
pool=0x00d620d8) Line 632 + 0x23 bytes
!svn_ra_dav__search_for_starting_props(svn_ra_dav_resource_t * *
rsrc=0x01beab80, const char * * missing_path=0x01beab84, ne_session_s *
sess=0x00d7c698, const char * url=0x00d68108, apr_pool_t *
pool=0x00d620d8) Line 668 + 0x16 bytes
!svn_ra_dav__get_baseline_props(svn_string_t * bc_relative=0x01beabd4,
svn_ra_dav_resource_t * * bln_rsrc=0x01beabd0, ne_session_s *
sess=0x00d7c698, const char * url=0x00d68108, long revision=-1, const
ne_propname * which_props=0x006063b8, apr_pool_t * pool=0x00d620d8)
Line 814 + 0x1e bytes
!svn_ra_dav__get_baseline_info(int * is_dir=0x00000000, svn_string_t *
bc_url=0x00000000, svn_string_t * bc_relative=0x00000000, long *
latest_rev=0x01beac58, ne_session_s * sess=0x00d7c698, const char *
url=0x00d68108, long revision=-1, apr_pool_t * pool=0x00d620d8) Line
904 + 0x2c bytes
!svn_ra_dav__get_latest_revnum(svn_ra_session_t * session=0x00d62190,
long * latest_revnum=0x01beac58, apr_pool_t * pool=0x00d620d8) Line
1246 + 0x20 bytes
!svn_client__get_revision_number(long * revnum=0x01beac58,
svn_ra_session_t * ra_session=0x00d62190, const svn_opt_revision_t *
revision=0x01beace8, const char * path=0x00d561d0, apr_pool_t *
pool=0x00d620d8) Line 65 + 0x10 bytes
!svn_client__repos_locations(const char * * start_url=0x01beacc8,
svn_opt_revision_t * * start_revision=0x01beaccc, const char * *
end_url=0x01beacd4, svn_opt_revision_t * * end_revision=0x01beacd0,
svn_ra_session_t * ra_session=0x00d62190, const char * path=0x00d561d0,
const svn_opt_revision_t * revision=0x01beace8, const svn_opt_revision_t
* start=0x01beacd8, const svn_opt_revision_t * end=0x01beacf8,
svn_client_ctx_t * ctx=0x00d5d150, apr_pool_t * pool=0x00d620d8) Line
762 + 0x16 bytes
!svn_client__ra_session_from_path(svn_ra_session_t * *
ra_session_p=0x01bead58, long * rev_p=0x01bead60, const char * *
url_p=0x01bead4c, const char * path_or_url=0x00d561d0, const
svn_opt_revision_t * peg_revision_p=0x01beadf0, const svn_opt_revision_t
* revision=0x01beae08, svn_client_ctx_t * ctx=0x00d5d150, apr_pool_t *
pool=0x00d620d8) Line 928 + 0x34 bytes
!svn_client__checkout_internal(long * result_rev=0x00000000, const char
* url=0x00d6dff8, const char * path=0x00d66c78, const svn_opt_revision_t
* peg_revision=0x01beadf0, const svn_opt_revision_t *
revision=0x01beae08, int recurse=1, int ignore_externals=0, int *
timestamp_sleep=0x00000000, svn_client_ctx_t * ctx=0x00d5d150,
apr_pool_t * pool=0x00d560b8) Line 86 + 0x23 bytes
!svn_client_checkout2(long * result_rev=0x00000000, const char *
URL=0x00d6dff8, const char * path=0x00d66c78, const svn_opt_revision_t *
peg_revision=0x01beadf0, const svn_opt_revision_t * revision=0x01beae08,
int recurse=1, int ignore_externals=0, svn_client_ctx_t *
ctx=0x00d5d150, apr_pool_t * pool=0x00d560b8) Line 219 + 0x34 bytes
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by Samay <ge...@hotmail.com>.
> Ben Collins-Sussman wrote:
>> Well, there must be some code somewhere that is calling the svn_auth.h
>> API incorrectly. The API says that the client code should first call
>> svn_auth_first_credentials(), which will either return creds or not.
>> If creds are returned and fail to authenticate, then the caller can
>> try fetching 'more' credentials by calling svn_auth_next_credentials()
>> over and over, until we run out of creds (creds comes back as NULL.)
>>
>> If you look at the code to first_credentials(), the only time the
>> iter_baton is set to NULL is when there are no creds at all. That
>> means the some SSPI code must be calling next_credentials() even when
>> first_credentials() returned nothing! That would very wrong. :-)
>>
>> I can't help with debugging the SSPI scenario, but perhaps we should
>> patch next_credentials() to check that (iter_baton != NULL), and throw
>> a real svn_error_t if it is.
>
> What would happen if neon tries different auth methods while increasing
> the 'attempt' value each time? Would that maybe cause this kind of crash?
> Because as I understand, Subversion only calls
> svn_auth_first_credentials() if 'attempt' is zero, but it should call this
> for every 'new' auth method. I could be wrong here of course.
>
> Stefan
>
> --
it works fine if compiled with Neon 0.25.5. Previous discussion abotu 1.4.0
SVN win32 is here http://svn.haxx.se/users/archive-2006-09/0955.shtml
Issue is reproducible on both on Win32 & Linux when used with https &
SPNego/SSPI authentication if SVN (1.4.0, 1.4.1) is compiled with Neon
0.26.x.
regards
Samay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by Stefan Küng <to...@gmail.com>.
Ben Collins-Sussman wrote:
> On 11/13/06, Stefan Küng <to...@gmail.com> wrote:
>
>> What would happen if neon tries different auth methods while increasing
>> the 'attempt' value each time? Would that maybe cause this kind of
>> crash? Because as I understand, Subversion only calls
>> svn_auth_first_credentials() if 'attempt' is zero, but it should call
>> this for every 'new' auth method. I could be wrong here of course.]
>
> I'm a bit confused here. It sounds like you're saying that both neon
> and the subversion libraries each have independent, parallel
> implementations of 'trying multiple auth methods'. If so, yes, that
> can lead to bad things.
>
> The design of subversion's libraries is such that different auth
> methods are encapsulated in 'provider' vtables, and then when the RA
> layer calls first_creds(), next_creds(), etc.... the different
> providers are automatically attempted.
>
> But, if neon has its *own* concept of trying multiple auth methods,
> then yeah, that could result in some weird mis-use of svn_auth.h. I
> don't remember that being the case, though...
I've now spent several hours trying to reproduce the problem but was not
successful. Seems I still have something on my setup that isn't the way
it has to be to get the crash.
But I've compared neon 0.25.5 with 0.26.2. And I think I found why it
crashes. As I mentioned before, I suspect that neon counts the auth
attempts over *all* auth methods, while subversion does that per-auth
method.
And by comparing ne_auth.c in 0.25.5 and 0.26.2 I found that neon 0.26.2
indeed has the 'attempt' stored in the auth_request struct, while neon
0.25.5 has it stored in the auth_session struct.
Anyone here who can reproduce the crash and fix this? I hope I could at
least help with finding the reason for the crash.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Thu, Dec 07, 2006 at 08:29:49PM -0700, D.J. Heap wrote:
> On 12/7/06, Joe Orton <jo...@manyfish.co.uk> wrote:
> >Sorry, I didn't see this thread before, the neon mailing list has been
> >wedged. That's clearly a regression in the new 0.26 auth code, the
> >first invocation of the creds callback should always be zero, the API
> >description for the callback is clear about that. I'll fix this in
> >neon.
>
> Ok, thanks, Joe. Do you see any problem with leaving the workaround
> in place (at least for a while)?
I never followed up on that, sorry: no, it looks fine AFAICT. The
attempt handling in neon is fixed in 0.26.3 (as far as I've tested).
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by "D.J. Heap" <dj...@gmail.com>.
On 12/7/06, Joe Orton <jo...@manyfish.co.uk> wrote:
> Sorry, I didn't see this thread before, the neon mailing list has been
> wedged. That's clearly a regression in the new 0.26 auth code, the
> first invocation of the creds callback should always be zero, the API
> description for the callback is clear about that. I'll fix this in
> neon.
Ok, thanks, Joe. Do you see any problem with leaving the workaround
in place (at least for a while)?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by Joe Orton <jo...@manyfish.co.uk>.
Sorry, I didn't see this thread before, the neon mailing list has been
wedged. That's clearly a regression in the new 0.26 auth code, the
first invocation of the creds callback should always be zero, the API
description for the callback is clear about that. I'll fix this in
neon.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[neon] Re: crash in 1.4.2 and https
Posted by Joe Orton <jo...@manyfish.co.uk>.
Sorry, I didn't see this thread before, the neon mailing list has been
wedged. That's clearly a regression in the new 0.26 auth code, the
first invocation of the creds callback should always be zero, the API
description for the callback is clear about that. I'll fix this in
neon.
Regards,
joe
_______________________________________________
neon mailing list
neon@webdav.org
http://mailman.webdav.org/mailman/listinfo/neon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by "D.J. Heap" <dj...@gmail.com>.
On 11/16/06, Stefan Küng <to...@gmail.com> wrote:
> Finally, I was able to reproduce the problem. I really was close to
> giving up here.
>
> How to reproduce:
> Set up an apache server on a windows domain or one which uses
> authentication with the mod_auth_sspi module against a windows domain.
>
> The configuration should look something like this:
[snip]
Awesome, thanks Stefan! I was able to reproduce the crash on trunk
and confirm that your patch fixed it.
Are there any objections to committing this patch and nominating it
for backport? I'm not a ra_dav auth expert, but it seems like we'll
need this unless/until neon exposes more of the SSPI auth workings in
some kind of new API.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by Stefan Küng <to...@gmail.com>.
Ben Collins-Sussman wrote:
> On 11/13/06, Stefan Küng <to...@gmail.com> wrote:
>
>> What would happen if neon tries different auth methods while increasing
>> the 'attempt' value each time? Would that maybe cause this kind of
>> crash? Because as I understand, Subversion only calls
>> svn_auth_first_credentials() if 'attempt' is zero, but it should call
>> this for every 'new' auth method. I could be wrong here of course.]
>
> I'm a bit confused here. It sounds like you're saying that both neon
> and the subversion libraries each have independent, parallel
> implementations of 'trying multiple auth methods'. If so, yes, that
> can lead to bad things.
>
> The design of subversion's libraries is such that different auth
> methods are encapsulated in 'provider' vtables, and then when the RA
> layer calls first_creds(), next_creds(), etc.... the different
> providers are automatically attempted.
>
> But, if neon has its *own* concept of trying multiple auth methods,
> then yeah, that could result in some weird mis-use of svn_auth.h. I
> don't remember that being the case, though...
Finally, I was able to reproduce the problem. I really was close to
giving up here.
How to reproduce:
Set up an apache server on a windows domain or one which uses
authentication with the mod_auth_sspi module against a windows domain.
The configuration should look something like this:
<Location /svn/local>
DAV svn
SVNPath C:/SVN/local
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIOfferBasic On
SSPIDomain TESTSERVER
SSPIOmitDomain on
SSPIUsernameCase lower
AuthName "Subversion"
AuthzSVNAccessFile C:/svnaccess.txt
SSLRequireSSL
Require valid-user
</Location>
But that's not enough. The user trying to access that repository must
*not* be part of the domain!
Now, here's what's happening:
neon tries to authenticate first with SSPI. It tries two times before
giving up with SSPI and falling back to basic authentication. Subversion
doesn't even know about the SSPI authentication because the auth
callbacks aren't called.
Now, when neon falls back to basic authentication, the 'attempt' param
is not 0(!) but 2, since there were already two previous authentication
attempts with SSPI. Subversion checks the 'attempt' param for 0, and
only calls svn_auth_first_credentials() if it is 0.
But because the 'attempt' param is already 2, Subversion never calls
svn_auth_first_credentials() but calls svn_auth_next_credentials()
instead, which leads to the crash.
Since there was a change between neon 0.25.x and 0.26.x which causes the
'attempt' param to be now per-session than per-request, I don't know if
this should be fixed in Subversion or neon. (that's why I'm cc'ing the
neon list).
I would propose the following fix:
Index: subversion/libsvn_ra_dav/session.c
===================================================================
--- subversion/libsvn_ra_dav/session.c (revision 22315)
+++ subversion/libsvn_ra_dav/session.c (working copy)
@@ -85,7 +85,7 @@
if (! ras->callbacks->auth_baton)
return -1;
- if (attempt == 0)
+ if ((attempt == 0)||(ras->auth_iterstate == NULL))
{
const char *realmstring;
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: crash in 1.4.2 and https
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 11/13/06, Stefan Küng <to...@gmail.com> wrote:
> What would happen if neon tries different auth methods while increasing
> the 'attempt' value each time? Would that maybe cause this kind of
> crash? Because as I understand, Subversion only calls
> svn_auth_first_credentials() if 'attempt' is zero, but it should call
> this for every 'new' auth method. I could be wrong here of course.]
I'm a bit confused here. It sounds like you're saying that both neon
and the subversion libraries each have independent, parallel
implementations of 'trying multiple auth methods'. If so, yes, that
can lead to bad things.
The design of subversion's libraries is such that different auth
methods are encapsulated in 'provider' vtables, and then when the RA
layer calls first_creds(), next_creds(), etc.... the different
providers are automatically attempted.
But, if neon has its *own* concept of trying multiple auth methods,
then yeah, that could result in some weird mis-use of svn_auth.h. I
don't remember that being the case, though...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by Stefan Küng <to...@gmail.com>.
Ben Collins-Sussman wrote:
> Well, there must be some code somewhere that is calling the svn_auth.h
> API incorrectly. The API says that the client code should first call
> svn_auth_first_credentials(), which will either return creds or not.
> If creds are returned and fail to authenticate, then the caller can
> try fetching 'more' credentials by calling svn_auth_next_credentials()
> over and over, until we run out of creds (creds comes back as NULL.)
>
> If you look at the code to first_credentials(), the only time the
> iter_baton is set to NULL is when there are no creds at all. That
> means the some SSPI code must be calling next_credentials() even when
> first_credentials() returned nothing! That would very wrong. :-)
>
> I can't help with debugging the SSPI scenario, but perhaps we should
> patch next_credentials() to check that (iter_baton != NULL), and throw
> a real svn_error_t if it is.
What would happen if neon tries different auth methods while increasing
the 'attempt' value each time? Would that maybe cause this kind of
crash? Because as I understand, Subversion only calls
svn_auth_first_credentials() if 'attempt' is zero, but it should call
this for every 'new' auth method. I could be wrong here of course.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Küng wrote:
> C. Michael Pilato wrote:
>> Ben Collins-Sussman wrote:
>>> I can't help with debugging the SSPI scenario, but perhaps we should
>>> patch next_credentials() to check that (iter_baton != NULL), and throw
>>> a real svn_error_t if it is.
>>
>> Nope, an abort() is exactly what we want here. This isn't a user-level
>> problem, it's an API misuse. We have aborts and asserts and good ol'
>> crashes for exactly this scenario.
>
> While I don't object against an assert, I really have to object against
> using an abort(). You can use that for console applications which are
> single threaded. But for UI apps which usually have multiple threads,
> that only leads to a crash which is hard to debug because the crash
> happens somewhere completely unrelated to where the abort() is.
I misspoke -- assert() is absolutely right. (I was trying to speak
generally about the desire to die-horribly-on-invalid-input, and should
have been more careful with my terminology.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: crash in 1.4.2 and https
Posted by Stefan Küng <to...@gmail.com>.
C. Michael Pilato wrote:
> Ben Collins-Sussman wrote:
>> I can't help with debugging the SSPI scenario, but perhaps we should
>> patch next_credentials() to check that (iter_baton != NULL), and throw
>> a real svn_error_t if it is.
>
> Nope, an abort() is exactly what we want here. This isn't a user-level
> problem, it's an API misuse. We have aborts and asserts and good ol'
> crashes for exactly this scenario.
While I don't object against an assert, I really have to object against
using an abort(). You can use that for console applications which are
single threaded. But for UI apps which usually have multiple threads,
that only leads to a crash which is hard to debug because the crash
happens somewhere completely unrelated to where the abort() is.
I just tried to reproduce the crash here with my test setup (since I
have to use a different account and restart my server to boot another
OS, this always takes a lot of time). Unfortunately, I couldn't
reproduce this. So I can't provide much more information than the stack
trace I already sent.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman wrote:
> I can't help with debugging the SSPI scenario, but perhaps we should
> patch next_credentials() to check that (iter_baton != NULL), and throw
> a real svn_error_t if it is.
Nope, an abort() is exactly what we want here. This isn't a user-level
problem, it's an API misuse. We have aborts and asserts and good ol'
crashes for exactly this scenario.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: crash in 1.4.2 and https
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Well, there must be some code somewhere that is calling the svn_auth.h
API incorrectly. The API says that the client code should first call
svn_auth_first_credentials(), which will either return creds or not.
If creds are returned and fail to authenticate, then the caller can
try fetching 'more' credentials by calling svn_auth_next_credentials()
over and over, until we run out of creds (creds comes back as NULL.)
If you look at the code to first_credentials(), the only time the
iter_baton is set to NULL is when there are no creds at all. That
means the some SSPI code must be calling next_credentials() even when
first_credentials() returned nothing! That would very wrong. :-)
I can't help with debugging the SSPI scenario, but perhaps we should
patch next_credentials() to check that (iter_baton != NULL), and throw
a real svn_error_t if it is.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: crash in 1.4.2 and https
Posted by Stefan Küng <to...@gmail.com>.
Stefan Küng wrote:
> The crash happens with any command accessing a repository via https, but
> as I found out not all the time. I'm still in contact with one of the
> users who runs into this problem, so I'll keep posting more information
> as I get them. BTW: the crash also happens with the command line client
> version 1.4.2.
>
> The crash happens because in svn_auth_next_credentials, the second
> function parameter is NULL, and the third line after the function start
> the line
> provider_set_t *table = state->table;
> then accesses the NULL param 'state'.
Just got more information:
the crash only happens (as far as I could find out) if SSPI
authentication is enabled.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org