On 8/2/06, Branko Èibej <brane@xbc.nu> wrote:
> Garrett Rooney wrote:
> > On 8/2/06, Branko Èibej <brane@xbc.nu> wrote:
> >
> >> Wait, does that mean the thing crashed when the RA lib (that loads the
> >> FS lib) was unloaded, not when the FS lib itself was unloaded? Thing is,
> >> the svn_fs_t can still live longer than the DSO, I think, because its
> >> ultimately global grandparent pool is created before the common pool and
> >> dso cache.
> >
> > Yes, libsvn_fs was unloaded as a result of libsvn_ra_local being
> > unloaded. I think we're still ok though, since the global pool we now
> > create within libsvn_fs has to be created before the one in
> > libsvn_fs_base, and since pools are destroyed in reverse order that
> > means the global env cache will be destroyed before the global pool in
> > libsvn_fs that results in the unloading of libsvn_fs_base...
> >
> > Or am I missing something here?
> Yes ... the last svn_fs_t's pool can still be destroyed, and the
> svn_fs_t's pool cleanups -- which need the BDB env handle -- called
> after the DSO is unloaded. Also, the RA loader has no effect on when the
> FS DSO is loaded in, e.g., svnserve.
>
> One probable scenario, using ra_local:
>
> 1. the client will create its working pool; that pool's parent is the
> global pool
> 2. the RA loader creates its DSO cache, in another (new) global pool
> 3. the RA layer calls svn_fs_open/create, passing in the client's
> working pool, returning an svn_fs_t
> 4. the FS loader loads the FS backend; things happen, and eventually
> the BDB environment cache is created in another global pool
>
> Upon apr_terminate, the FS DSO will be unloaded, then the RA DSO, then
> the client's working pool that runs svn_fs_t's cleanups. BANG!
>
> A similar thing can happen in svnserve, except that there's no RA loader
> in the way:
>
> 1. svnserve creates a request pool for the current request, whose
> parent is a global pool
> 2. svnserve calls svn_fs_open/create
> 3. the FS loader loads the FS backend, things happen, etc.
>
> Upon apr_terminate, we hear a very similar and quite as loud a BANG!
>
>
> Frankly I see no way around this short of insuring that the DSO cache's
> pool is created before the global pool that's the parent for any pool
> used by svn_fs_t's.
I think we've made a best effort attempt here, and it's about the most
we can do without requiring an initialization function that the user
calls before creating any other pools.
Another alternative might be moving the code that needs to run in pool
cleanups outside of loadable DSOs. That might be reasonable if
they're very small functions that only access data allocated on the
heap, not any globals that live in the DSOs. We could stick them in
libsvn_subr or something... Thoughts? I haven't really thought this
through all the way yet, but does anyone think this is an idea worth
pursuing?
-garrett
Received on Thu Aug 3 01:06:57 2006