On Wed, Mar 29, 2006 at 05:54:29PM +0100, Philip Martin wrote:
> Yes, that's it. Obviously the test intended to pass subpool here, and
> passing subpool does fix the problem, but does that indicate a bug in
> the editor code? Does passing the parent pool violate the editor API?
>
It doesn't violate the editor API per se, I'm fairly sure, since the
pools are all valid throughout the lifetime of editor use (I think).
But it might violate an assumption of the implementation.
It's possible that something in the BDB backend has recently introduced
a more stringent requirement on pool use (perhaps something like 'The
pool that you open the filesystem with [via the repos, in this case]
must outlive all the pools you operate on the filesystem with').
That seems strange, though.
Perhaps brane has some ideas? His BDB 4.4-support code had some
scary-looking code that I didn't understand, and it looked like it had
something to do with pool tracking.
One thing I still don't get, though: it looks like this is blowing up
on deletion of the subpool, not the parent pool. I thought it might be
something to do with the DSO being unloaded before a pool cleanup function
was running, but the DSO unload should be the _last_ pool cleanup to
run, since it's the first registered. So that doesn't make any sense,
and I think there's still some more debugging to do here.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 30 00:01:02 2006