Update: On Fri, Feb 28, 2014 at 12:45 PM, Lieven Govaerts <l...@apache.org> wrote: > Hi, > > On Wed, Feb 26, 2014 at 8:18 PM, Stefan Kueng <tortoise...@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.
I see that the connection queue contains 3 requests: 1) a ssltunnel+priority request, handler_baton points to the ssltunnel context 2) a normal request, handler baton also points to the ssltunnel context 3) a normal request, handler_baton points to the svn_ra_serf That second request shouldn't be there. This is a requeued CONNECT request but without the ssltunnel flag set. I'm quite confident that the problem is the handling of a cancelled CONNECT request in ssltunnel.c/handle_response(). Besides the fact that it requeues a CONNECT request as normal request, ssltunnel requests should not be requeued in case of closed/reset connections, because a new CONNECT request will be created when opening the new socket. Unfortunately I can't imagine a scenario which triggers this code path (I've tried some), so I can't write a test case to simulate it. To be continued. Lieven > >> >> Stefan >> >> -- >> ___ >> oo // \\ "De Chelonian Mobile" >> (_,\/ \_/ \ TortoiseSVN >> \ \_/_\_/> The coolest interface to (Sub)version control >> /_/ \_\ http://tortoisesvn.n
