From: "David Harris" <dharris@drh.net>
To: <new-httpd@apache.org>
Subject: RE: Memory leak in 1.3.6
Date: Fri, 6 Aug 1999 13:42:03 -0400
Message-ID: <00c201bee032$fe3dc440$0500a8c0@delf>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <Pine.LNX.3.96dg4.990806091406.17348k-100000@twinlark.arctic.org>
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org
Status: O


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