You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Cliff Woolley <jw...@virginia.edu> on 2002/04/16 18:36:12 UTC
Bugzilla bug 8034 - possible explanation of core dump (fwd)
I've had this one bite me in the ass as well. Same thing if you
accidentally get duplicate LoadModule lines in there on a shared module,
IIRC. Would there ever be a *legitimate* reason to load the same module
more than once?
--Cliff
---------- Forwarded message ----------
Date: Tue, 16 Apr 2002 14:52:07 +0100
From: Nigel Cole
To: jwoolley@apache.org
Subject: Bugzilla bug 8034 - possible explanation of core dump
I've also been getting a core dump from Apache 2.0.35 under Solaris,
but it turned out to be more of a missing feature than a bug: I'd
compiled mod_ssl statically, but accidentally left in the LoadModule
command for the previously-compiled dynamic version. Apache 2 loaded
the dynamic module without complaint, but later mySrvConfig returned
NULL when trying to get the server configuration structure, followed
by a segmentation fault when trying to write to the NULL structure
(line 593 of ssl_engine_config.c). After I removed the LoadModule
line, the problem went away.
I think, from the description of the second problem in the Bugzilla
report, the user may have made the same mistake.
Apache probably ought to detect that a module it's dynamically loading
has already been loaded statically, and at least generate a warning.
Re: [PATCH] Re: Bugzilla bug 8034 - possible explanation of core
dump (fwd)
Posted by Joshua Slive <jo...@slive.ca>.
Justin Erenkrantz wrote:
> On Fri, Apr 19, 2002 at 01:28:29PM -0400, Jeff Trawick wrote:
>
>>Jeff Trawick <tr...@attglobal.net> writes:
>>
>>
>>>It looks like mod_so already checks for duplicate LoadModule lines but
>>>it doesn't check for a LoadModule which attempts to override a
>>>built-in module. The patch below seems to implement a check for this
>>>second epossible error (a LoadModule directive for a built-in module).
>>
>>Does anybody besides Sander have any interest in this? I'm a little
>>reluctant to add the bloat unless more people think it is worthwhile.
>
>
> +1 (concept). I've been burned by this before. -- justin
Also +1 on concept. This happens fairly often because people switch
back and forth between static and DSO builds but forget to change their
config files (or, more accurately, have absolutely no idea that they
need to change their config files).
Joshua.
Re: [PATCH] Re: Bugzilla bug 8034 - possible explanation of core dump (fwd)
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Apr 19, 2002 at 01:28:29PM -0400, Jeff Trawick wrote:
> Jeff Trawick <tr...@attglobal.net> writes:
>
> > It looks like mod_so already checks for duplicate LoadModule lines but
> > it doesn't check for a LoadModule which attempts to override a
> > built-in module. The patch below seems to implement a check for this
> > second epossible error (a LoadModule directive for a built-in module).
>
> Does anybody besides Sander have any interest in this? I'm a little
> reluctant to add the bloat unless more people think it is worthwhile.
+1 (concept). I've been burned by this before. -- justin
Re: [PATCH] Re: Bugzilla bug 8034 - possible explanation of core
dump (fwd)
Posted by Cliff Woolley <jw...@virginia.edu>.
On 19 Apr 2002, Jeff Trawick wrote:
> Does anybody besides Sander have any interest in this? I'm a little
> reluctant to add the bloat unless more people think it is worthwhile.
I say do it... the symptoms when this happens are quite obscure. It's
bitten me at least once if not twice.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [PATCH] Re: Bugzilla bug 8034 - possible explanation of core dump (fwd)
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> It looks like mod_so already checks for duplicate LoadModule lines but
> it doesn't check for a LoadModule which attempts to override a
> built-in module. The patch below seems to implement a check for this
> second epossible error (a LoadModule directive for a built-in module).
Does anybody besides Sander have any interest in this? I'm a little
reluctant to add the bloat unless more people think it is worthwhile.
Thanks,
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: [PATCH] Re: Bugzilla bug 8034 - possible explanation of core dump (fwd)
Posted by Sander Striker <st...@apache.org>.
> From: trawick@rdu88-250-035.nc.rr.com
> [mailto:trawick@rdu88-250-035.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 17 April 2002 14:58
> Cliff Woolley <jw...@virginia.edu> writes:
>
> > I've had this one bite me in the ass as well. Same thing if you
> > accidentally get duplicate LoadModule lines in there on a shared module,
> > IIRC. Would there ever be a *legitimate* reason to load the same module
> > more than once?
>
> It looks like mod_so already checks for duplicate LoadModule lines but
> it doesn't check for a LoadModule which attempts to override a
> built-in module. The patch below seems to implement a check for this
> second epossible error (a LoadModule directive for a built-in module).
+1 in concept (haven't reviewed the patch)
Sander
[PATCH] Re: Bugzilla bug 8034 - possible explanation of core dump (fwd)
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley <jw...@virginia.edu> writes:
> I've had this one bite me in the ass as well. Same thing if you
> accidentally get duplicate LoadModule lines in there on a shared module,
> IIRC. Would there ever be a *legitimate* reason to load the same module
> more than once?
It looks like mod_so already checks for duplicate LoadModule lines but
it doesn't check for a LoadModule which attempts to override a
built-in module. The patch below seems to implement a check for this
second epossible error (a LoadModule directive for a built-in module).
Index: modules/mappers/mod_so.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_so.c,v
retrieving revision 1.48
diff -u -r1.48 mod_so.c
--- modules/mappers/mod_so.c 16 Mar 2002 18:26:57 -0000 1.48
+++ modules/mappers/mod_so.c 17 Apr 2002 12:57:52 -0000
@@ -220,6 +220,7 @@
/*
* check for already existing module
* If it already exists, we have nothing to do
+ * Check both dynamically-loaded modules and statically-linked modules.
*/
sconf = (so_server_conf *)ap_get_module_config(cmd->server->module_config,
&so_module);
@@ -233,6 +234,45 @@
return NULL;
}
}
+
+ for (i = 0; ap_preloaded_modules[i]; i++) {
+ const char *preload_name;
+ apr_size_t preload_len;
+ apr_size_t thismod_len;
+
+ modp = ap_preloaded_modules[i];
+
+ /* make sure we're comparing apples with apples
+ * make sure name of preloaded module is mod_FOO.c
+ * make sure name of structure being loaded is FOO_module
+ */
+
+ if (memcmp(modp->name, "mod_", 4)) {
+ continue;
+ }
+
+ preload_name = modp->name + strlen("mod_");
+ preload_len = strlen(preload_name) - 2;
+
+ if (strlen(modname) <= strlen("_module")) {
+ continue;
+ }
+ thismod_len = strlen(modname) - strlen("_module");
+ if (strcmp(modname + thismod_len, "_module")) {
+ continue;
+ }
+
+ if (thismod_len != preload_len) {
+ continue;
+ }
+
+ if (!memcmp(modname, preload_name, preload_len)) {
+ return apr_pstrcat(cmd->pool, "module ", modname,
+ " is built-in and can't be loaded",
+ NULL);
+ }
+ }
+
modi = apr_array_push(sconf->loaded_modules);
modi->name = modname;
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...