You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rob Hartill <ro...@imdb.com> on 1997/09/11 20:50:22 UTC
AddModule doesn't work correctly (fwd)
not acked
---------- Forwarded message ----------
Date: Thu, 11 Sep 1997 19:55:46 +0200
From: Xaver Fischer <xa...@munich.ixos.de>
To: "'apache-bugs@apache.org'" <ap...@apache.org>
Subject: AddModule doesn't work correctly
Bug report
Summary: The configuration command "AddModule" is "executed" after
the configuration of module specific structures. Therefore for
the added module these structures seems not to be initialized.
Hello,
first of all I like to say that the apache web server
is a very fine and a very generic software. Thank you for providing
such a professional software for free to the internet community.
Maybe I have found a bug in the source file "http_config.c" of
version 1.2.0, but I verified that there is no difference to the
version 1.2.4:
Let look at the following routines:
----------------------------------------------------------
server_rec *init_server_config(pool *p)
{
server_rec *s = (server_rec *)pcalloc (p, sizeof (server_rec));
s->port = DEFAULT_PORT;
s->server_admin = DEFAULT_ADMIN;
s->server_hostname = NULL;
s->error_fname = DEFAULT_ERRORLOG;
s->error_log = stderr;
s->srm_confname = RESOURCE_CONFIG_FILE;
s->access_confname = ACCESS_CONFIG_FILE;
s->timeout = DEFAULT_TIMEOUT;
s->keep_alive_timeout = DEFAULT_KEEPALIVE_TIMEOUT;
s->keep_alive_max = DEFAULT_KEEPALIVE;
s->keep_alive = 1;
s->next = NULL;
s->addrs = pcalloc(p, sizeof (server_addr_rec));
s->addrs->host_addr.s_addr = htonl (INADDR_ANY); /* NOT virtual
host;
* don't match any real network
* interface.
*/
s->addrs->host_port = 0; /* matches any port */
s->module_config = create_server_config (p, s);
s->lookup_defaults = create_default_per_dir_config (p);
return s;
}
server_rec *read_config(pool *p, pool *ptemp, char *confname)
{
server_rec *s = init_server_config(p);
init_config_globals(p);
/* All server-wide config files now have the SAME syntax... */
process_resource_config (s, confname, p, ptemp);
process_resource_config (s, s->srm_confname, p, ptemp);
process_resource_config (s, s->access_confname, p, ptemp);
fixup_virtual_hosts (p, s);
return s;
}
---------------------------------------------------------------------
In the first function "init_server()" the functions
"create_server_config()" and "create_default_per_dir_config()"
are called. These functions execute the funtions for creating
per-directory and per-server config structures for
every module in the modules list.
"init_server()" is called at the beginning of the function
"read_config()". Afterwards when reading the configuration with
"process_resource_config()" the command "AddModule" will expand
the list of prelinked modules. For some currently added module the
configuration is not done.
This makes trouble e.g. in "directory_walk()" when calling
"merge_per_dir_config()".
"merge_per_dir_config()" sees that the module provides a
merge per-dir function, but will call it with a NULL pointer
for the "base_vector[module->index]".
In my eyes a solution would be to call the functions
"create_server_config()" and "create_default_per_dir_config()"
after the reading of the configuration files.
To tell the whole story: The problems occurred at a changed version
of the file "http_config.c". I replaced the function "add_module()"
with the functions "add_module_in_order()" and "find_predecessor()":
---------------------------------
/*
* XF: With apache 1.2 AddModules links the module to the top of
* the list. But we want to add it at the position configured in
* Configuration.tmpl. For the management of the currently active
modules there
* exists a "linked list", where we have to insert the new module.
* This function insert the module on the right position.
*/
void add_module_in_order (module *m)
{
module *predecessor;
if (m->version != MODULE_MAGIC_NUMBER) {
fprintf(stderr, "httpd: module \"%s\" is not compatible with this "
"version of Apache.\n", m->name);
fprintf(stderr, "Please contact the author for the correct
version.\n");
exit(1);
}
predecessor = find_predecessor(m->module_index);
if(predecessor == NULL)
add_module(m);
else {
if (m->next != NULL)
fprintf(stderr, "Module configuration error:\n"
"The module structure seems to be corrupt!");
m->next = predecessor->next;
predecessor->next=m;
num_modules++;
}
}
/* XF: find the module with the least greater module_index */
module * find_predecessor(int index)
{
module *tmp = top_module;
if(!top_module) return NULL;
if(top_module->module_index<index) return NULL;
while (tmp->next && tmp->next->module_index>index)
tmp=tmp->next;
return tmp;
}
--------------------------------------------------------------------
I don't see any reason that there should be any difference concerning
the above described problem. In both cases ( if the module is added at
the top of the list or at some other position) the corresponding
entries in the per-directory and per-server config structures
are not initialized.
But maybe I didn't get the whole story.
Maybe you can use the two functions "add_module_in_order" and
"find_predecessor()" in some future version???
I hope someone finds some time to read this,
Thank you
Xaver Fischer
-------------------------------------------------------------------------
---
Xaver Fischer
Product Development
iXOS Software AG
Bretonischer Ring 12
D-85630 Grasbrunn
Tel.: +49(0)89 46005 - 301
Fax: +49(0)89 46005 -199
Email: Xaver.Fischer@munich.ixos.de
-------------------------------------------------------------------------
---
Re: AddModule doesn't work correctly (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
Well ... hmm. Ok. I think I'll just stick to saying that using dynamic
modules isn't the best if you want the most efficient code :) especially
now that you'll be chewing 256 bytes per-directory config. (Which
incidentally, hotwired has servers with over 100 configs... don't ask.)
Dean
On Fri, 12 Sep 1997, Alexei Kosut wrote:
> On Fri, 12 Sep 1997, Dean Gaudet wrote:
>
> > > 2. Add code to add_module() to exit and complain if you exceed your
> > > DYNAMIC_MODULE_LIMIT
> >
> > This works ... but it doesn't sit well with me ... I hate how we just
> > waste module indexes when the ClearModules happens. I'd prefer to see us
> > require Clear/AddModules to be the first directives in the conf files and
> > we use packed indicies and regenerate the default configs after we're done
> > with those directives.
>
> Actually, I was wrong about what Clear/AddModule does (it's been a while
> since I looked at that code). If you Clear/AddModule, total_modules isn't
> changed at all. It keeps the modules' index numbers from before. So
> that's not a problem. It will never reuse a number, though, for a
> different module, so corruption and confusion is not a problem (at least
> in 1.3 - in 1.2, it did and it was).
>
> Where you need more room is LoadModule (mod_dld and mod_dll) and
> friends.
>
> -- Alexei Kosut <ak...@organic.com>
>
>
Re: AddModule doesn't work correctly (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Fri, 12 Sep 1997, Dean Gaudet wrote:
> > 2. Add code to add_module() to exit and complain if you exceed your
> > DYNAMIC_MODULE_LIMIT
>
> This works ... but it doesn't sit well with me ... I hate how we just
> waste module indexes when the ClearModules happens. I'd prefer to see us
> require Clear/AddModules to be the first directives in the conf files and
> we use packed indicies and regenerate the default configs after we're done
> with those directives.
Actually, I was wrong about what Clear/AddModule does (it's been a while
since I looked at that code). If you Clear/AddModule, total_modules isn't
changed at all. It keeps the modules' index numbers from before. So
that's not a problem. It will never reuse a number, though, for a
different module, so corruption and confusion is not a problem (at least
in 1.3 - in 1.2, it did and it was).
Where you need more room is LoadModule (mod_dld and mod_dll) and
friends.
-- Alexei Kosut <ak...@organic.com>
Re: AddModule doesn't work correctly (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 12 Sep 1997, Alexei Kosut wrote:
> On Fri, 12 Sep 1997, Dean Gaudet wrote:
>
> > I think I'd like to see DYNAMIC_MODULE_LIMIT default to 0 if it's
> > otherwise undefiend, and mod_dld, mod_dll or whatever they're called have
> > Configure time rules added to them to bump DYNAMIC_MODULE_LIMIT to
> > whatever is needed.
> >
> > Or I'll just add -DDYNAMIC_MODULE_LIMIT=0 to my performance page :)
>
> Is the extra 256 bytes per config really that performance-impeding? It's
> only done at startup - merge_per_dir_configs() uses its own allocation
> of total_modules, for example.
Well it's possible there'd be enough (suppose there's several hundred
virtual hosts) to waste a bunch of pages... I dunno. It just seems like a
waste to me.
> Anyhow, here's a patch that:
>
> 1. Fixes create_empty_config (the previous patch)
> 2. Add code to add_module() to exit and complain if you exceed your
> DYNAMIC_MODULE_LIMIT
This works ... but it doesn't sit well with me ... I hate how we just
waste module indexes when the ClearModules happens. I'd prefer to see us
require Clear/AddModules to be the first directives in the conf files and
we use packed indicies and regenerate the default configs after we're done
with those directives.
But at a minimum your patch here should go in, so +1.
> 3. Adds #ifndefs around #define DYNAMIC_MODULE_LIMIT so you can change it
> at compile-time without editing httpd.h
I just committed this 'cause I wanted to add it to my perf page (and it's
sort of something missed in the previous patches that added #ifndef
wrappers).
Dean
Re: AddModule doesn't work correctly (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Fri, 12 Sep 1997, Dean Gaudet wrote:
> I think I'd like to see DYNAMIC_MODULE_LIMIT default to 0 if it's
> otherwise undefiend, and mod_dld, mod_dll or whatever they're called have
> Configure time rules added to them to bump DYNAMIC_MODULE_LIMIT to
> whatever is needed.
>
> Or I'll just add -DDYNAMIC_MODULE_LIMIT=0 to my performance page :)
Is the extra 256 bytes per config really that performance-impeding? It's
only done at startup - merge_per_dir_configs() uses its own allocation
of total_modules, for example.
Anyhow, here's a patch that:
1. Fixes create_empty_config (the previous patch)
2. Add code to add_module() to exit and complain if you exceed your
DYNAMIC_MODULE_LIMIT
3. Adds #ifndefs around #define DYNAMIC_MODULE_LIMIT so you can change it
at compile-time without editing httpd.h
Index: main/http_config.c
===================================================================
RCS file: /export/home/cvs/apachen/src/main/http_config.c,v
retrieving revision 1.78
diff -u -r1.78 http_config.c
--- http_config.c 1997/08/31 21:28:49 1.78
+++ http_config.c 1997/09/12 22:16:30
@@ -83,8 +83,15 @@
* of modules which control just about all of the server operation.
*/
-/* total_modules is the number of modules linked in. */
+/* total_modules is the number of modules that have been linked
+ * into the server.
+ */
static int total_modules = 0;
+/* dynamic_modules is the number of modules that have been added
+ * after the pre-linked ones have been set up. It shouldn't be larger
+ * than DYNAMIC_MODULE_LIMIT.
+ */
+static int dynamic_modules = 0;
module *top_module = NULL;
typedef int (*handler_func)(request_rec *);
@@ -117,7 +124,8 @@
void *
create_empty_config (pool *p)
{
- void **conf_vector = (void **)pcalloc(p, sizeof(void*) * total_modules);
+ void **conf_vector = (void **)pcalloc(p, sizeof(void*) *
+ (total_modules+DYNAMIC_MODULE_LIMIT));
return (void *)conf_vector;
}
@@ -472,8 +480,17 @@
}
if (m->module_index == -1) {
m->module_index = total_modules++;
+ dynamic_modules++;
+
+ if (dynamic_modules > DYNAMIC_MODULE_LIMIT) {
+ fprintf(stderr, "httpd: module \"%s\" could not be loaded, because"
+ " the dynamic\n", m->name);
+ fprintf(stderr, "module limit was reached. Please increase "
+ "DYNAMIC_MODULE_LIMIT and recompile.\n");
+ exit(1);
+ }
}
-
+
/* Some C compilers put a complete path into __FILE__, but we want
* only the filename (e.g. mod_includes.c). So check for path
* components (Unix and DOS), and remove them.
Index: main/httpd.h
===================================================================
RCS file: /export/home/cvs/apachen/src/main/httpd.h,v
retrieving revision 1.147
diff -u -r1.147 httpd.h
--- httpd.h 1997/09/07 15:39:48 1.147
+++ httpd.h 1997/09/12 22:16:34
@@ -88,7 +88,9 @@
#endif /* DOCUMENT_LOCATION */
/* Max. number of dynamically loaded modules */
+#ifndef DYNAMIC_MODULE_LIMIT
#define DYNAMIC_MODULE_LIMIT 64
+#endif /* DYNAMIC_MODULE_LIMIT */
/* Default administrator's address */
#define DEFAULT_ADMIN "[no address given]"
-- Alexei Kosut <ak...@organic.com>
Re: AddModule doesn't work correctly (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
I think I'd like to see DYNAMIC_MODULE_LIMIT default to 0 if it's
otherwise undefiend, and mod_dld, mod_dll or whatever they're called have
Configure time rules added to them to bump DYNAMIC_MODULE_LIMIT to
whatever is needed.
Or I'll just add -DDYNAMIC_MODULE_LIMIT=0 to my performance page :)
Dean
On Thu, 11 Sep 1997, Alexei Kosut wrote:
> On Thu, 11 Sep 1997, Dean Gaudet wrote:
>
> Oh, and by the way, Xavier.. hope you don't mind being cc-ed on these
> messages; our development list generates a lot of traffic, as you can
> imagine, even on just one issue.
>
> > > When <Directory> is called, a per-dir config will be created, using
> > > create_default_per_dir_config(), which creates enough space for
> > > total_modules + DYNAMIC_MODULE_LIMIT. So there's plenty of room for the
> > > new module.
> >
> > Nope:
> >
> > void *new_dir_conf = create_per_dir_config (cmd->pool);
> >
> > which calls create_empty_config which only uses total_modules. (Which
> > breaks the rest of your logic :)
>
> Ergh. Okay, so you're right. Why are you calling AddModule (or
> LoadModule) anywhere but at the top of httpd.conf, anyway? That's where
> it should be - that's where it worked when I tested all this stuff last
> month :)
>
> Maybe this will help. Actually, add_module should test to make sure
> DYNAMIC_MODULE_LIMIT isn't being exceeded, too:
>
> Index: http_config.c
> ===================================================================
> RCS file: /export/home/cvs/apachen/src/main/http_config.c,v
> retrieving revision 1.78
> diff -u -r1.78 http_config.c
> --- http_config.c 1997/08/31 21:28:49 1.78
> +++ http_config.c 1997/09/11 22:23:55
> @@ -117,7 +117,7 @@
> void *
> create_empty_config (pool *p)
> {
> - void **conf_vector = (void **)pcalloc(p, sizeof(void*) * total_modules);
> + void **conf_vector = (void **)pcalloc(p, sizeof(void*) * total_modules+DYNAMIC_MODULE_LIMIT);
> return (void *)conf_vector;
> }
>
>
>
> -- Alexei Kosut <ak...@organic.com>
>
>
Re: AddModule doesn't work correctly (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Thu, 11 Sep 1997, Dean Gaudet wrote:
Oh, and by the way, Xavier.. hope you don't mind being cc-ed on these
messages; our development list generates a lot of traffic, as you can
imagine, even on just one issue.
> > When <Directory> is called, a per-dir config will be created, using
> > create_default_per_dir_config(), which creates enough space for
> > total_modules + DYNAMIC_MODULE_LIMIT. So there's plenty of room for the
> > new module.
>
> Nope:
>
> void *new_dir_conf = create_per_dir_config (cmd->pool);
>
> which calls create_empty_config which only uses total_modules. (Which
> breaks the rest of your logic :)
Ergh. Okay, so you're right. Why are you calling AddModule (or
LoadModule) anywhere but at the top of httpd.conf, anyway? That's where
it should be - that's where it worked when I tested all this stuff last
month :)
Maybe this will help. Actually, add_module should test to make sure
DYNAMIC_MODULE_LIMIT isn't being exceeded, too:
Index: http_config.c
===================================================================
RCS file: /export/home/cvs/apachen/src/main/http_config.c,v
retrieving revision 1.78
diff -u -r1.78 http_config.c
--- http_config.c 1997/08/31 21:28:49 1.78
+++ http_config.c 1997/09/11 22:23:55
@@ -117,7 +117,7 @@
void *
create_empty_config (pool *p)
{
- void **conf_vector = (void **)pcalloc(p, sizeof(void*) * total_modules);
+ void **conf_vector = (void **)pcalloc(p, sizeof(void*) * total_modules+DYNAMIC_MODULE_LIMIT);
return (void *)conf_vector;
}
-- Alexei Kosut <ak...@organic.com>
Re: AddModule doesn't work correctly (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 11 Sep 1997, Alexei Kosut wrote:
> When <Directory> is called, a per-dir config will be created, using
> create_default_per_dir_config(), which creates enough space for
> total_modules + DYNAMIC_MODULE_LIMIT. So there's plenty of room for the
> new module.
Nope:
void *new_dir_conf = create_per_dir_config (cmd->pool);
which calls create_empty_config which only uses total_modules. (Which
breaks the rest of your logic :)
Dean
Re: AddModule doesn't work correctly (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Thu, 11 Sep 1997, Dean Gaudet wrote:
> On Thu, 11 Sep 1997, Alexei Kosut wrote:
>
> > So for 1.3 I rewrote add_module() to increase total_modules when it adds
> > modules, so any additional config vector creation is at least large
> > enough (possibly too large, but I don't worry about that too much).
>
> But what about a config:
>
> <Directory /bleck>
> asdf
> </Directory>
>
> AddModule mod_dig_this
>
> ?
When <Directory> is called, a per-dir config will be created, using
create_default_per_dir_config(), which creates enough space for
total_modules + DYNAMIC_MODULE_LIMIT. So there's plenty of room for the
new module.
> When merge_per_dir_config is done with that directory later it's possible
> that mod_dig_this will reference past the end of the vector. One
> possible solution is to change the vector to include a length.
When merge_per_dir_config() is called, it uses total_modules to decide
how many modules to initialize its config for. By that point,
total_modules is large enough to include mod_dig_this, because AddModule
has incremented total_modules by one.
> But worse ... if a ClearModules is done after something like that
> directory then it's possible that two modules will get the configs for
> each other ... which could be why Xaver was mentioning that AddModules
> shouldn't do things out of order.
ClearModules does not do a total_modules = 0. Nothing ever decrements
total_modules. ClearModules will give each new AddModuled module a new
number higher than any module that had been loaded before.
Again, this is only for 1.3. Apache 1.2 is very defenitely screwed up in
this manner, and what you say is in fact the case there. All sorts of odd
things can, and will, happen.
-- Alexei Kosut <ak...@organic.com>
Re: AddModule doesn't work correctly (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 11 Sep 1997, Alexei Kosut wrote:
> So for 1.3 I rewrote add_module() to increase total_modules when it adds
> modules, so any additional config vector creation is at least large
> enough (possibly too large, but I don't worry about that too much).
But what about a config:
<Directory /bleck>
asdf
</Directory>
AddModule mod_dig_this
?
When merge_per_dir_config is done with that directory later it's possible
that mod_dig_this will reference past the end of the vector. One
possible solution is to change the vector to include a length.
But worse ... if a ClearModules is done after something like that
directory then it's possible that two modules will get the configs for
each other ... which could be why Xaver was mentioning that AddModules
shouldn't do things out of order.
Dean
Re: AddModule doesn't work correctly (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Thu, 11 Sep 1997, Dean Gaudet wrote:
> Ewww. Alexei I'm surprised you haven't run into problems from this on
> WIN32 yet.
>
> void *
> create_empty_config (pool *p)
> {
> void **conf_vector = (void **)pcalloc(p, sizeof(void*) * total_modules);
> return (void *)conf_vector;
> }
>
> Notice total_modules ... this is limited to exactly the total that's
> compiled in at compile time.
Note quite: create_default_per_dir_config() and create_server_config()
use total_modules + DYNAMIC_MODULE_LIMIT. They are the only ones that are
called before config files are parsed, and any LoadModules are picked
up. create_empty_config() is only called later, after the config files
have been parsed and total_modules is what it says, the total number of
modules you have loaded in:
The 1.2 add_module() is completely screwed up, if you're doing anything
other than a straight ClearModuleList/AddModules. It was broken when the
AddModule code was written, but that code just barely avoided tickling
the bugs. I discovered that when I wrote mod_dll for the Win32 port.
So for 1.3 I rewrote add_module() to increase total_modules when it adds
modules, so any additional config vector creation is at least large
enough (possibly too large, but I don't worry about that too much).
Xavier, try downloading 1.3a1 (or 1.3b1, which should be released
shortly), and see if things work with it. I believe they will.
-- Alexei Kosut <ak...@organic.com>
Re: AddModule doesn't work correctly (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
Ewww. Alexei I'm surprised you haven't run into problems from this on
WIN32 yet.
void *
create_empty_config (pool *p)
{
void **conf_vector = (void **)pcalloc(p, sizeof(void*) * total_modules);
return (void *)conf_vector;
}
Notice total_modules ... this is limited to exactly the total that's
compiled in at compile time.
I think the correct fix is for add_module to extend these arrays and fill
in the new slots by calling the new module's create_foo_config methods.
ugly!
BTW, Xaver, AddModules is allowed to redefine the ordering of modules ...
that's why it links at the top of the list.
Dean
On Thu, 11 Sep 1997, Rob Hartill wrote:
>
> not acked
>
> ---------- Forwarded message ----------
> Date: Thu, 11 Sep 1997 19:55:46 +0200
> From: Xaver Fischer <xa...@munich.ixos.de>
> To: "'apache-bugs@apache.org'" <ap...@apache.org>
> Subject: AddModule doesn't work correctly
>
> Bug report
>
> Summary: The configuration command "AddModule" is "executed" after
> the configuration of module specific structures. Therefore for
> the added module these structures seems not to be initialized.
>
> Hello,
>
> first of all I like to say that the apache web server
> is a very fine and a very generic software. Thank you for providing
> such a professional software for free to the internet community.
>
> Maybe I have found a bug in the source file "http_config.c" of
> version 1.2.0, but I verified that there is no difference to the
> version 1.2.4:
> Let look at the following routines:
>
> ----------------------------------------------------------
> server_rec *init_server_config(pool *p)
> {
> server_rec *s = (server_rec *)pcalloc (p, sizeof (server_rec));
>
> s->port = DEFAULT_PORT;
> s->server_admin = DEFAULT_ADMIN;
> s->server_hostname = NULL;
> s->error_fname = DEFAULT_ERRORLOG;
> s->error_log = stderr;
> s->srm_confname = RESOURCE_CONFIG_FILE;
> s->access_confname = ACCESS_CONFIG_FILE;
> s->timeout = DEFAULT_TIMEOUT;
> s->keep_alive_timeout = DEFAULT_KEEPALIVE_TIMEOUT;
> s->keep_alive_max = DEFAULT_KEEPALIVE;
> s->keep_alive = 1;
> s->next = NULL;
> s->addrs = pcalloc(p, sizeof (server_addr_rec));
> s->addrs->host_addr.s_addr = htonl (INADDR_ANY); /* NOT virtual
> host;
> * don't match any real network
> * interface.
> */
> s->addrs->host_port = 0; /* matches any port */
>
> s->module_config = create_server_config (p, s);
> s->lookup_defaults = create_default_per_dir_config (p);
>
> return s;
> }
>
> server_rec *read_config(pool *p, pool *ptemp, char *confname)
> {
> server_rec *s = init_server_config(p);
>
> init_config_globals(p);
>
> /* All server-wide config files now have the SAME syntax... */
>
> process_resource_config (s, confname, p, ptemp);
> process_resource_config (s, s->srm_confname, p, ptemp);
> process_resource_config (s, s->access_confname, p, ptemp);
>
> fixup_virtual_hosts (p, s);
>
> return s;
> }
> ---------------------------------------------------------------------
>
> In the first function "init_server()" the functions
> "create_server_config()" and "create_default_per_dir_config()"
> are called. These functions execute the funtions for creating
> per-directory and per-server config structures for
> every module in the modules list.
>
> "init_server()" is called at the beginning of the function
> "read_config()". Afterwards when reading the configuration with
> "process_resource_config()" the command "AddModule" will expand
> the list of prelinked modules. For some currently added module the
> configuration is not done.
>
> This makes trouble e.g. in "directory_walk()" when calling
> "merge_per_dir_config()".
> "merge_per_dir_config()" sees that the module provides a
> merge per-dir function, but will call it with a NULL pointer
> for the "base_vector[module->index]".
>
> In my eyes a solution would be to call the functions
> "create_server_config()" and "create_default_per_dir_config()"
> after the reading of the configuration files.
>
> To tell the whole story: The problems occurred at a changed version
> of the file "http_config.c". I replaced the function "add_module()"
> with the functions "add_module_in_order()" and "find_predecessor()":
>
> ---------------------------------
> /*
> * XF: With apache 1.2 AddModules links the module to the top of
> * the list. But we want to add it at the position configured in
> * Configuration.tmpl. For the management of the currently active
> modules there
> * exists a "linked list", where we have to insert the new module.
> * This function insert the module on the right position.
> */
> void add_module_in_order (module *m)
> {
> module *predecessor;
>
> if (m->version != MODULE_MAGIC_NUMBER) {
> fprintf(stderr, "httpd: module \"%s\" is not compatible with this "
> "version of Apache.\n", m->name);
> fprintf(stderr, "Please contact the author for the correct
> version.\n");
> exit(1);
> }
>
> predecessor = find_predecessor(m->module_index);
>
> if(predecessor == NULL)
> add_module(m);
> else {
> if (m->next != NULL)
> fprintf(stderr, "Module configuration error:\n"
> "The module structure seems to be corrupt!");
>
> m->next = predecessor->next;
> predecessor->next=m;
> num_modules++;
> }
> }
>
> /* XF: find the module with the least greater module_index */
> module * find_predecessor(int index)
> {
> module *tmp = top_module;
> if(!top_module) return NULL;
> if(top_module->module_index<index) return NULL;
>
> while (tmp->next && tmp->next->module_index>index)
> tmp=tmp->next;
> return tmp;
> }
> --------------------------------------------------------------------
>
> I don't see any reason that there should be any difference concerning
> the above described problem. In both cases ( if the module is added at
> the top of the list or at some other position) the corresponding
> entries in the per-directory and per-server config structures
> are not initialized.
> But maybe I didn't get the whole story.
>
> Maybe you can use the two functions "add_module_in_order" and
> "find_predecessor()" in some future version???
>
> I hope someone finds some time to read this,
>
> Thank you
> Xaver Fischer
>
>
>
> -------------------------------------------------------------------------
> ---
> Xaver Fischer
> Product Development
> iXOS Software AG
> Bretonischer Ring 12
> D-85630 Grasbrunn
>
> Tel.: +49(0)89 46005 - 301
> Fax: +49(0)89 46005 -199
> Email: Xaver.Fischer@munich.ixos.de
> -------------------------------------------------------------------------
> ---
>
>
>