register_hooks problem

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

After a few hours on the plane, I'm certain of why DAV is crashing
when loaded as a loadable module.

While I'm not certain of every reason, it's pretty obvious that
dav and dav_fs are unloaded by the mod_so cleanup before their
own cleanups are invoked.  Plus there are linkage problems, where
the address of the code/data in dav is not fixed up before the
addresses in question get kicked around.

I'll have fixes to it all by tommorow night (cvs seems down this
evening.)  But it means two -big- changes.

Number one - whoever decided the ap_global_hook_pool is good for
modules was horribly wrong.  Modules can be removed.  Their own
registered cleanups segfault.  So register_hooks grows a apr_pool_t
arg for lifetime management (of course, it should be a cmd pool,
since that's the pool modules are loaded into.)

Number two - there are no global pools.  Every pool -must- be a
descendant of another.  So I'm picturing a pool assert in debug
build that the pool allocated is a child of the pool in question.
This is the only way we will ever catch -every- lifetime issue.

Besides those, I have several patches to go in once CVS returns 
that fix assorted win32 issues.  I am not optimizing, simply fixing 
broken behaviors.  I'm trying to keep things very consistent going 
into beta 1, excepting our real api issues.

Bill

Re: register_hooks problem

[Greg Stein <gs...@lyra.org>]

On Wed, Jan 17, 2001 at 01:05:51AM -0600, William A. Rowe, Jr. wrote:
>...
> While I'm not certain of every reason, it's pretty obvious that
> dav and dav_fs are unloaded by the mod_so cleanup before their
> own cleanups are invoked.

I wondered about out cleanup strategy a little while back (not specifically
related to mod_dav; too bad it was found there first :-( ). Figured that the
cleanups were just independent enough that it wasn't causing a problem.
Guess not :-)

Note that the "right" thing would be to use separate pools for dynload
modules and for the other allocs/cleanups. You could then control the
cleanup more precisely (either sibling pools for the "other" pool would be a
sub-pool of the dynload pool).

>...
> Number one - whoever decided the ap_global_hook_pool is good for
> modules was horribly wrong.  Modules can be removed.  Their own
> registered cleanups segfault.  So register_hooks grows a apr_pool_t
> arg for lifetime management (of course, it should be a cmd pool,
> since that's the pool modules are loaded into.)

Yay! I've been wanting to do this for a while, but couldn't figure out a
justification for that widespread of a change :-)

You'll see bitches about the lack of a pool in the FILTER_POOL symbol in
util_filter.c, dav/main/providers.c::dav_register_provider, and a few other
places. Basically, searching for ap_global_hook_pool will find a number of
gripes :-)

> Number two - there are no global pools.  Every pool -must- be a
> descendant of another.  So I'm picturing a pool assert in debug
> build that the pool allocated is a child of the pool in question.
> This is the only way we will ever catch -every- lifetime issue.

Seems fine.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/