Garrett Rooney wrote:
> On 6/7/06, Greg Hudson <ghudson@mit.edu> 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, let's see what he has to say about it.
I certainly _think_ I implemented the pool cleanup as discussed above. I
remember I had tests that tripped on the out-of-order pool cleanup, and
after I fixed that, those tests started to work again. Obviously I
didn't test as things thoroughly as I should have ...
I'm beginning to wonder what happens to BDB environments after a fork,
and if we do in fact have any open before we fork in svnserve. I don't
believe so, but it's something to look at. Of course, that would be
easier for me if I had a *nix box for testing available, which I don't
at the moment.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 8 14:22:07 2006