On Fri, Jun 21, 2013 at 3:26 PM, Stefan Küng <tortoisesvn_at_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
Received on 2013-06-23 02:57:11 CEST