Dean wrote:
> Not only is there the above bug, but ClearModuleList leaves total_modules
> and dynamic_modules set to whatever they were beforehand. Oops I guess
> you shouldn't ever put more than one ClearModuleList in your configuration
> file... and doesn't it mess up across restarts?
I don't see why ap_clear_module_list should mess with total_modules or
dynamic_modules, as it only clears the top_module linked list. It's not
actually unloading the module just wiping clean the top_module list which
should be rebuilt afterwards. The top_module list is rebuilt by ap_add_module
which can be called just fine for an already loaded module. It will just sense
that the module is not on the top_modules list (by checking m->next) and add it
if needed.
> Oh! and you shouldn't ever call ap_remove_module on a statically loaded
> module! because ap_remove_module decrements dynamic_modules, even if it
> wasn't incremented when loading the module.
Actually dynamic_modules is not deceremented for non-dynamic modules, because
ap_remove_modules is not called for statically loaded modules.
Here's how I understand it...
The only place I see ap_remove_module is called from is ap_remove_loaded_module
which is only called from mod_so.c :unload_module, which is registered as a
cleanup in mod_so.c:load_module right after the call to ap_add_loaded_module.
So, ap_remove_module is only called to remove dynamic modules.. and all of them
are unloaded all together.
The only place total_modules is incremented is from ap_add_module only when the
module being loaded is dynamic because of the m->module_index == -1 test.
ap_add_module is only called for dynamic modules from ap_add_loaded_module. It
is also called from ap_setup_prelinked_modules and ap_add_named_module, but
those calls will not cause a total_modules++ because of the m->module_index
== -1 test. The call from ap_setup_prelinked_modules will not because it's
already loaded and thus it will have a modue_index. The call from
ap_add_named_module will not because it only will call with modules that are on
the ap_loaded_modules list, which have already been loaded and thus have a
module_index.
So it ends up that mod_so.c:load_module is the only place that causes
total_modules to be incremented and it also registers a cleanup which is the
only way that ap_remove_module will be called... so decrementing total_modules
in ap_remove_module works out and closes the loop.
> wow. This stuff is a confusing mess. I guess I'll apply David's patch,
> it can't make it any worse.
I agree.. it is a confusing mess. Seems that some nice comments in the source
code would go a long way towards making it more understanding. Would the AG be
interested in that?
- David Harris
Principal Engineer, DRH Internet Services
|