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

Re: Another 1.4 release critical bug

From: Branko Čibej <brane_at_xbc.nu>
Date: 2006-08-03 00:55:16 CEST

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.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 3 00:56:02 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.