D.J. Heap wrote:
> On 3/24/07, D.J. Heap <djheap@gmail.com> wrote:
> [snip]
>>
>> Thanks, it looks good. It appears to be a shutdown/cleanup ordering
>> problem in the bdb stuff after a quick first glance. I know there was
>> a lot of pain and work on that issue a while ago -- should be fun to
>> figure out. I'll try to work on it as soon as I can but it's not very
>> high on my list at the moment.
>
>
> I've been debugging this and narrowed it down quite a bit. I'm
> puzzled how it works on other OS' at all, though, so I think I'm
> mis-understanding something.
>
> In libsvn_fs_base\bdb\env.c the bdb_init_cb function allocates the bdb
> cache stuff in the global pool (I think?) and registers a cleanup
> callback to clear_cache.
>
> Then in final process termination (after unloading modules) when
> Apache cleans out the global pool
> (apr\memory\unix\apr_pools.c:apr_pool_terminate), it tries to call the
> clear_cache function -- but it's already been unloaded by then and so
> goes boom.
>
> Am I mis-understanding the sequence of things or does it work
> differently on unixy OS'?
>
> The crash goes away if I comment out the clear_cache cleanup registration.
I think we decided once that this was a bug in DSO handling and really
has to be fixed in APR -- or at least, that APR should give apps a way
to delay the actual module unload until after pool cleanup. And I can't
imagine how it would work on other platforms, either. Unless it's
(again) about "freed" memory still having the original contents ... I
wouldn't be at all surprised if a DSOs memory remained mapped to the
proces some indefinite time after unload, on some systems (it would
scare me, though :).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 1 08:41:17 2007