On 6/7/06, Greg Hudson <ghudson@mit.edu> wrote:
> On Wed, 2006-06-07 at 14:57 -0400, Garrett Rooney wrote:
> > Ok, so I figured that part out. The issue is pool
> > creation/destruction ordering. The bdb environment cache is created
> > after the connection pool, so it's destroyed before it (Last In, First
> > Out). This means that by the time apr_terminate comes around and
> > destroys the connection pool the bdb environment has already been
> > paniced as part of the cache destruction process.
>
> This feels like a problem best addressed in libsvn_fs_base, not in
> svnserve. Why does destroying the environment cache pool first result
> in a panicked environment?
I'm sorry, I misspoke. It's not that it's paniced, it's that it's
invalidated (see the invalidate_env_baton callback in
libsvn_fs_base/bdb/env.c). I believe it's part of the infrastructure
that keeps you from running close twice on the same bdb environment.
When the bdb env cache pool is destroyed it invalidates all
outstanding cached environments. I'm not entirely clear on the
details, but I expect it's something related to making sure we don't
access memory after its pool is destroyed.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 8 03:38:47 2006