On Fri, Jun 21, 2013 at 3:26 PM, Stefan Küng <tortoise...@gmail.com> wrote: >... > I'm not sure, but another crash report seems related to this: > https://www.crash-server.com/Problem.aspx?ClientID=tsvn&ProblemID=26624 > > The stacktrace of this one: >... > libsvn_tsvn.dll!handle_response(serf_request_t * request=0x000000df49d27f18, > serf_bucket_t * response=0x000000df49d2a678, svn_ra_serf__handler_t * > handler=0x000000df49d2a5d8, int * serf_status=0x0000000000000000, apr_pool_t > * scratch_pool=0x000000df49d2dbb8) Line 2060 C > libsvn_tsvn.dll!handle_response_cb(serf_request_t * > request=0x000000df49d27f18, serf_bucket_t * response=0x000000df49d2a5d8, > void * baton=0x000007fe00000000, apr_pool_t * > scratch_pool=0x0000000000000000) Line 2096 C >...
I don't think this is the same. You appear to have a valid request/response there. At this point, I'd say it is unrelated. Needs to be fixed, sure, but not related to proxy auth and SSL tunnels. > The problem here is that in svn_wc__conflict_invoke_resolver(), the call > if (cancel_func) > SVN_ERR(cancel_func(cancel_baton)); > > calls into invalid memory. The exception is actually "Access violation > executing code" so it seems that here too a wrong/invalid ctx is used. No idea right now... (focused on the fixes Lieven just made) Cheers, -g
