[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: crash in serf credential callback

From: Lieven Govaerts <lgo_at_apache.org>
Date: Fri, 28 Feb 2014 12:45:22 +0100


On Wed, Feb 26, 2014 at 8:18 PM, Stefan Kueng <tortoisesvn_at_gmail.com> wrote:
> Hi,
> There's a crash happening in libsvn_ra_serf\util.c in the function
> svn_ra_serf__credentials_callback. There's a full crash dump available from
> here:
> https://www.crash-server.com/Problem.aspx?ClientID=tsvn&ProblemID=58311
> From what I can figure out from that crash dump is that the 'session' baton
> is not set (it's NULL), which leads to a segfault in the line:
> *username = apr_pstrdup(pool, session->proxy_username);
> The http return code is 407.
> But I can't figure out if this is a problem in serf or the svn library.
> Maybe one of you guys can have a look at this?

I'm looking into this report but haven't reached a conclusion yet. The
dump doesn't contain a correct value for each function parameters and
local variables, so debugging isn't easy.

The user is trying to connect over a http proxy to a https server; The
proxy requests username & password (Basic authn scheme). I see that
the baton passed to svn_ra_serf__credentials_callback isn't NULL, but
is a pointer to the ssl tunnel bucket context.

This points me to serf__provide_credentials.

Normally that function should setup the next request - the one
provided by the application that lead to the setup of the ssl tunnel -
so that the response_handler from that request can be passed to the
credentials callback.

That mechanism must have failed. I see that the first request is
indeed a ssltunnel request, but the conn->state is SERF_CONN_INIT
instead of SERF_CONN_SETUP_SSLTUNNEL. This explains why the mechanism
to find and setup the first application request isn't triggered.

The remaining question is how the connection can be in SERF_CONN_INIT
state while handling authentication of the response to the CONNECT
request. The only place where the connection state is reset is in
reset_connection, but I haven't found a scenario yet where that
function is called before an outstanding response on that connection
is handled.


> Stefan
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest interface to (Sub)version control
> /_/ \_\ http://tortoisesvn.n
Received on 2014-02-28 12:46:19 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.