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

Re: [PATCH] Server-side Cyrus SASL support

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-08-25 18:36:33 CEST

On 8/25/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> On 8/25/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > On 8/25/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> >
> > > Hi Garrett,
> > >
> > > Could you test the following patch?
> > >
> > > It solves the problem by maintaining a count of how many sasl contexts
> > > were created, and only calling sasl_done() when all of them are
> > > destroyed (the count starts from 1, because we also decrement it in
> > > sasl_done_cb). It seems to work for me (i.e. the test runs
> > > successfully).
> >
> > Unfortunately, that's not going to work. The problem isn't that we
> > call sasl_done(), then later on call sasl_dispose() on some existing
> > sasl context (well, that's probably A problem, but it's not THE
> > problem). The problem is that if we do any sasl stuff after sasl_pool
> > is destroyed then the mutex locking/unlocking that happens in the
> > subsequent calls to sasl_done() or sasl_dispose() will try to
> > lock/unlock mutexes allocated in memory that's potentially been reused
> > because it was allocated out of sasl_pool.
> Ok, but this patch by itself is still valid, right? After all, it
> somehow manages to stop svn from crashing on my machine, despite the
> other issues :)

You might want to try with an APR that was built with
--enable-pool-debug, that tends to trip up such things...

> > I'm thinking that we may be able to get away with sticking if
> > (sasl_done) return; in various places, since this will only ever
> > happen at global shutdown time, at which point we've already assumed
> > that we're in single threaded mode, so locking isn't needed...
> I'll add those checks. Should I submit a separate patch, or
> incorporate them in the other one?

One patch that does both should be fine.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 25 18:39:09 2006

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.