On 4/1/07, Branko Èibej <brane@xbc.nu> wrote:
[snip]
>
> 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 :).
>
Ah, I've seen that kind of thing before and that would explain it.
I'm not deadly on the details, but is that pretty much the only way to
actually fix this? We have a common_pool in the loader that appears
to be trying to address this same kind of issue -- is there some way
to pass it down so the bdb cache can use that? Or is that pool
inappropriate for some reason?
DJ
Received on Sun Apr 1 15:32:10 2007