On Thu, Jun 20, 2013 at 10:30 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Jun 20, 2013 at 2:19 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>> Hi,
>>
>> Another crash that's climbing up in the crash report statistics for TSVN.
>> Seems to be related to the previously discussed problem with checkouts in
>> TSVN.
Thanks Stefan.
>> The stack trace:
>>
>> BowPad
>>
>> libsvn_tsvn.dll!svn_ra_serf__credentials_callback(char * *
>> username=0xffffffffffffffff, char * * password=0x0000000002ba0210,
>> serf_request_t * request=0x0000000002ba0280, void *
>> baton=0x0000000002c12588, int code=407, const char *
>> authn_type=0x000007fee0bf0b58, const char * realm=0x0000000002c12b60,
>> apr_pool_t * pool=0x0000000002bb8258) Line 1789 C
>
> The 407 code means a proxy authorization is needed.
>
> The problem in this stack frame is the username address. It clearly
> has a problematic value. It should only be about four bytes off from
> the password value.
>
>> libsvn_tsvn.dll!serf__handle_basic_auth(int code=-524813808, serf_request_t
>> * request=0x0000000002ba8368, serf_bucket_t * response=0x0000000000000001,
>> const char * auth_hdr=0x0000000002bb30be, const char *
>> auth_attr=0x0000000002bb30be, void * baton=0x0000000002bac270, apr_pool_t *
>> pool=0x0000000002ba0198) Line 89 C
>
> The code parameter in this traceback is clearly incorrect. It should
> be 407, just like what got passed to the callback.
>
> Either these tracebacks are wonky, or there may be some stack smashing
> going on. Stefan?
I guess it's optimized code.
>>...
>> The crash is in libsvn_ra_serf\util.c, Snippet
>> svn_ra_serf__credentials_callback, line 1789:
>> BowPad *username = apr_pstrdup(pool, session->proxy_username);
>> *password = apr_pstrdup(pool, session->proxy_password);
>
> Was session bad? Or was the proxy_username bad?
>
Looks like it's the authentication handling when setting up a SSL
tunnel that's at fault here, at least I can easily reproduce it with
an apache http proxy connetion to a https repo.
The ssl tunnel is started by a CONNECT request created by serf. When
the proxy requests credentials, serf will call back to the
application. As the application doesn't know about this request, it
doesn't get a valid baton either, so can't get baton->session ...
That baton it gets is the ctx used by the ssltunnel code.
Hm, have to think about how we can solve this. Not sure it can be done
with the existing API.
> Thx,
> -g
Lieven
Received on 2013-06-20 23:06:47 CEST