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

Re: BDB 4.4 + forking svnserve weirdness (issue 2564)

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2006-06-13 14:41:09 CEST

Greg Hudson wrote:
> On Wed, 2006-06-07 at 21:38 -0400, Garrett Rooney wrote:
>> 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.
> So, we had a big discussion of this issue in the past, and I thought we
> came up with a proper solution, where destroying the cache pool would
> cleanly close the environments, and subsequent destruction of the FS
> object pools would do nothing. If we didn't, then Branko must have
> messed up, and I don't think the fix is to force the pool destruction
> order in svnserve or any other program.
Well, it turns out that I did mess up, in a way, but it was an
unavoidable way with the method described above. The short story is that
we can't afford to close the DB_ENV handle while FS objects are still
around, because those objects own handles to the databases themselves.
Even if they didn't, we still couldn't afford to close the environment,
because the FS object cleanup may have to access the environment. The
only way to avoid that would be to pepper the code with validation
checks wherever we call a BDB function, and I want to avoid that at all

There's another option, one I had thought about in the past: in order to
keep the environment descriptor (and its reference count!) around long
enough, I'd have to allocate it from the heap, not from a pool. That's
not as sexy as the current code and it means mixing malloc and
apr_palloc, but it's much more likely to actually work.

BTW, Garrett's fix in svnserve/main.c elegantly avoids this problem
/within svnserve/, but we we don't have that kind of control over pool
lifetimes in general. I shudder to imagine what happens in a GUI, say,

Since the whole point of the BDB-4.4 work was to make that back-end
stable, we can't leave things as they are. I'm working on a patch now.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 13 14:41:47 2006

This is an archived mail posted to the Subversion Dev mailing list.