Bug 8169

Probing further, I found that mod_perl does not fully work unless it is
statically compiled into the web server as opposed to a DSO.  Could RedHat
supply a SecureWeb RPM with mod_perl statically compiled into it?

I have the same problem, although I have found that using any 'use' statements
in the startup script.  See apache's bugfix database for more info: PR 5221.  I
have also found that it seems to be dependent on the redhat build.  I have two
different machines with RH6.1 on them, same rpms, everything.  It works on one,
but not on the other.  The only difference I can think of immediately is that
one was upgraded to 6.1, but the other was installed clean.

It looks like it died in boot_DBI in the dXARGS macro.
$ gdb httpd
(gdb) r -X


Starting program: /usr/sbin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x4053e3df in boot_DBI (cv=0x82818e4) at DBI.c:2873
2873        dXSARGS;
(gdb) bt
#0  0x4053e3df in boot_DBI (cv=0x82818e4) at DBI.c:2873
#1  0x405e2306 in ?? () from /etc/httpd/modules/libperl.so
#2  0x4060c17d in ?? () from /etc/httpd/modules/libperl.so
#3  0x405b4641 in ?? () from /etc/httpd/modules/libperl.so
#4  0x405b6989 in ?? () from /etc/httpd/modules/libperl.so
#5  0x405cf54f in ?? () from /etc/httpd/modules/libperl.so
#6  0x405c8c36 in ?? () from /etc/httpd/modules/libperl.so
#7  0x405fab26 in ?? () from /etc/httpd/modules/libperl.so
#8  0x405fb591 in ?? () from /etc/httpd/modules/libperl.so
#9  0x4060c17d in ?? () from /etc/httpd/modules/libperl.so
#10 0x405b4641 in ?? () from /etc/httpd/modules/libperl.so
#11 0x405b6989 in ?? () from /etc/httpd/modules/libperl.so
#12 0x405cf54f in ?? () from /etc/httpd/modules/libperl.so
#13 0x405cd080 in ?? () from /etc/httpd/modules/libperl.so
#14 0x405c8d64 in ?? () from /etc/httpd/modules/libperl.so
#15 0x405fab26 in ?? () from /etc/httpd/modules/libperl.so
#16 0x405fb591 in ?? () from /etc/httpd/modules/libperl.so
#17 0x4060c17d in ?? () from /etc/httpd/modules/libperl.so
#18 0x405b496c in ?? () from /etc/httpd/modules/libperl.so
#19 0x405a011d in ?? () from /etc/httpd/modules/libperl.so
#20 0x4059be05 in ?? () from /etc/httpd/modules/libperl.so
#21 0x80531b9 in ap_clear_module_list ()
#22 0x805350c in ap_handle_command ()
#23 0x8053558 in ap_srm_command_loop ()
#24 0x80538c7 in ap_process_resource_config ()
#25 0x8056e48 in ap_exists_config_define ()
#26 0x80532fc in ap_clear_module_list ()
#27 0x805350c in ap_handle_command ()
#28 0x8053558 in ap_srm_command_loop ()
#29 0x80538c7 in ap_process_resource_config ()
#30 0x8056e48 in ap_exists_config_define ()
#31 0x80532fc in ap_clear_module_list ()
#32 0x805350c in ap_handle_command ()
#33 0x8053558 in ap_srm_command_loop ()
#34 0x80538c7 in ap_process_resource_config ()
#35 0x8053f44 in ap_read_config ()
#36 0x805ae47 in ap_child_terminate ()
#37 0x805b4fb in main ()
#38 0x400b91eb in __libc_start_main (main=0x805b290 <main>, argc=2,
argv=0xbffffd34,
    init=0x804e684 <_init>, fini=0x80794ec <_fini>, rtld_fini=0x4000a610
<_dl_fini>,
    stack_end=0xbffffd2c) at ../sysdeps/generic/libc-start.c:90
(gdb) The program is running.  Exit anyway? (y or n) y

We have a 6.0 machine in house here with (E-commerce Server Boxed) that has no
problem with mod_perl and preloaded DBI connections and a mod_php.src.rpm built
with mysql support.. <- no problems.

I downloaded and installed off the net 6.1 and installed the same
securewebserver and develpackages as the 6.0 machine and installed mod_perl and
preloaded DBI built mod_php3.src.rpm for mysql (same as above basically)
as a backup machine. <- worked fine.

We purchased 6.1 professional edition with the newer secureweb packages and
installed with same configuration mod_perl with preloaded DBI and
mod_php3.src.rpm with mysql support...apache dies upon startup. So I uninstalled
the newer secureweb and devel packages and replaced them with the older packages
from the 6.0 Ecommerce Server box. Still Apache dies with no error messages.
So I disable mod_php3 and Apache starts up fine (commenting out the module).
Leaving both mod_perl and mod_php in the config but removing the
PerlModule Apache::DBI would also allow Apache to start.
Hours later i change the order in wich mod_perl and mod_php3 (perl first) are
loaded and apache works fine.

So we tried this on another machine with the 6.1 professional package and
the newer secureweb and devel rpms. Mostly the same situation except that
PerlModule Apache::DBI will kill apache no matter what I've tried.
using a startup.pl file as follows

#!/usr/bin/perl -w


$ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or die "GATEWAY_INTERFACE not Perl!";

use Apache::Registry;
use Apache::Status;
use Apache::DBI;
use strict;

$Apache::DBI::DEBUG = 2;

Apache Still Dies with no errors, comment out Apache::DBI
and it still dies. Comment out Apache::Status and Apache will start with
mod_php3 enabled.

I'm guessing the problem is related to the Apache::Status module
Also during this process the first net installed 6.1 machine with the older
packages worked fine with mod_php3 loading first followed by mod_perl and then
Apache::DBI, however I accidently uninstalled the web server and mod_everthing
(was logged into the wrong machine duh) upon reinstall of the secure web server
and all mod_'s (same exact setup) the Apache wouldn't start and I had to switch
the loading order of the mod_perl and mod_php3 (perl and Apache::DBI first).

our tests of 6.2 show that if we load the perl module before the php3 module,
the above cases will work out of the box.

I encountered the same problem, with the vanilla apache (non-secure) shipped
with RedHat 6.1. Having the mod_perl DSO loaded before/without php/php3 did not
help. However loading the mod_perl DSO before any other DSO fixed the problem.
The first LoadModule and AddModule statements should be for mod_perl when
implementing this quick-fix.