Yup, this is it. If I build it without DSO support, it appears to work. Of course I build this with mod_php, mod_ssl, mod_perl, and a couple of custom modules. So running without DSO support isn't to easy. I guess I can attempt to build mod_perl in, but keep DSO support and dynamic load the rest of the modules. Will try that.
* Kyle Dawkins ([EMAIL PROTECTED]) [020728 18:58]: > Hey Greg et al. > > I'd betcha your problem is almost certainly caused by your use of DSOs. If > you *really* want to prune your system down to see where your bug is, then > build apache and mod_perl statically. There was a very well-known bug that > caused DBI to segfault if it was run under a DSO. Please rebuild your > binary and then let us know if that was the problem. > > Kyle Dawkins > Central Park Software > http://www.centralparksoftware.com > > > > Okay, I've been staring at this problem for close to 48 hours straight > > now and have finally narrowed it down to a set of lines of code. > > > > So let me first expand. > > > > I currently have a system running, with Apache 1.3.14 and Mod_Perl 1.24 > > on Redhat 7.0 (yeah REALLY REALLY ancient) and Perl 5.005003. It also > > has mod_ssl, and several other modules loaded, but for the sake of the > > problems I am having, I completely removed those. > > > > This actually runs perl scripts that connect and talk to (yeah dig > > this), Postgres, Mysql, and Informix. The root of my problems, as I > > have finally found, is Informix. > > > > In our httpd.conf, we utilize a PerlScript directive to preload a bunch > > of environment variables, and other stuff at startup. The script is > > pretty nasty and harry, and buried deep within it happened to be a call > > to Informix. > > > > So for the record, the current system (ancient stuff) works. > > > > So the problems began. I decided to upgrade to Apache 1.3.26 and > > Mod_Perl 1.27 on Debian Woody (3.0) and Perl 5.006001. I also built all > > the other libraries, and than the fun began. > > > > At first, I just got seg faults attempting to start apache. But as I > > have said above, I have narrowed it down to a set of lines of code that > > cause it to fail. > > > > So if I build Apache 1.3.26 and Mod_perl 1.27 by themselves, using > > pretty straight forward options.. > > > > Apache > > ------ > > CC="gcc" \ > > CFLAGS="-g" \ > > LIBS="-L/home/grumple/src/test/lib > > -L/home/grumple/src/test/system/lib " \ > > ./configure \ > > "--prefix=/home/grumple/src/test/system" \ > > "--enable-module=most" \ > > "--enable-shared=max" \ > > "--with-layout=GNU" \ > > "--disable-rule=EXPAT" \ > > "$@" > > ---------------------- > > > > and > > > > Mod_perl > > -------- > > perl Makefile.PL PERL_USELARGEFILES=0 PERL_DEBUG=1 USE_APXS=1 > WITH_APXS=/home/grumple/src/test/system/sbin/apxs EVERYTHING=1 > INC=/home/grumple/src/test/system/include > > ---------------------- > > > > and than my conf > > > > httpd.conf > > ---------- > > AccessConfig /dev/null > > ResourceConfig /dev/null > > > > LoadModule env_module libexec/mod_env.so > > LoadModule config_log_module libexec/mod_log_config.so > > LoadModule mime_module libexec/mod_mime.so > > LoadModule autoindex_module libexec/mod_autoindex.so > > LoadModule dir_module libexec/mod_dir.so > > LoadModule alias_module libexec/mod_alias.so > > LoadModule access_module libexec/mod_access.so > > LoadModule auth_module libexec/mod_auth.so > > LoadModule setenvif_module libexec/mod_setenvif.so > > > > AddModule mod_env.c > > AddModule mod_log_config.c > > AddModule mod_mime.c > > AddModule mod_autoindex.c > > AddModule mod_dir.c > > AddModule mod_alias.c > > AddModule mod_access.c > > AddModule mod_auth.c > > AddModule mod_setenvif.c > > > > ServerType standalone > > ServerRoot "/home/grumple/src/test/system" > > > > PidFile /var/tmp/run/test.pid > > LockFile /var/tmp/test.lock > > ScoreBoardFile /var/tmp/test.scoreboard > > > > Timeout 300 > > KeepAlive On > > MaxKeepAliveRequests 100 > > KeepAliveTimeout 15 > > MinSpareServers 2 > > MaxSpareServers 10 > > StartServers 3 > > MaxClients 256 > > MaxRequestsPerChild 1000 > > > > LoadModule perl_module libexec/libperl.so > > AddModule mod_perl.c > > > > ServerName grumple > > Port 6180 > > > > Listen 6180 > > > > ServerAdmin yeah@right > > DocumentRoot /home/grumple/src/test/www/htdocs > > > > <Directory /> > > Options FollowSymLinks > > AllowOverride None > > </Directory> > > > > <Directory "/home/grumple/src/test/www/htdocs"> > > Options FollowSymLinks > > AllowOverride None > > Order allow,deny > > Allow from all > > </Directory> > > > > DirectoryIndex index.tp index.htm index.html index.cgi > > AccessFileName .htaccess > > <Files .htaccess> > > Order allow,deny > > Deny from all > > </Files> > > > > UseCanonicalName On > > TypesConfig "/home/grumple/src/test/system/etc/httpd/mime.types" > > DefaultType text/plain > > HostnameLookups Off > > LogLevel warn > > > > LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" > combined > > CustomLog "/var/tmp/logs/test.access" combined > > ErrorLog "/var/tmp/logs/test.errors" > > > > ReadmeName README > > HeaderName HEADER > > > > IndexOptions FancyIndexing > > IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t > > > > AddEncoding x-compress Z > > AddEncoding x-gzip gz > > > > AddHandler send-as-is asis > > AddHandler imap-file map > > > > BrowserMatch "Mozilla/2" nokeepalive > > BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 > > BrowserMatch "RealPlayer 4\.0" force-response-1.0 > > BrowserMatch "Java/1\.0" force-response-1.0 > > BrowserMatch "JDK/1\.0" force-response-1.0 > > > > AddHandler cgi-script .cgi > > PerlScript /var/tmp/test.pl > > > > AddType application/x-x509-ca-cert .crt > > AddType application/x-pkcs7-crl .crl > > > > ErrorDocument 404 /index.tp > > ---------------------- > > > > And here's the magical part, the test.pl script that causes the problem. > > > > test.pl > > ------- > > BEGIN { > > unshift(@INC, qw( > > /home/grumple/src/test/lib/perl5 > > /home/grumple/src/test/system/lib/perl5 > > )); > > } > > > > use strict; > > > > use DBI; > > use DBD::Informix; > > > > ## informix connection params > > $ENV{'INFORMIXDIR'} ||= '/opt/informix'; > > $ENV{'INFORMIXSERVER'} ||= 'test_tcp'; > > $ENV{'LD_LIBRARY_PATH'} .= ":$ENV{'INFORMIXDIR'}/lib"; > > > > my $catalog = 'test'; > > my $constr = join(':', 'dbi', 'Informix', $catalog); > > my $user = 'test'; > > my $password = 'test'; > > > > my $dbh = DBI->connect($constr,$user,$password); > > > > $dbh->disconnect(); > > > > 1; > > ---------------------- > > > > So all looks good right? Well it does, other than running above yields > > the following crash in GDB. > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x400e7a90 in free () from /lib/libc.so.6 > > (gdb) bt > > #0 0x400e7a90 in free () from /lib/libc.so.6 > > #1 0x40255d3b in Perl_safefree () from /usr/lib/libperl.so.5.6 > > #2 0x402705eb in Perl_sv_clear () from /usr/lib/libperl.so.5.6 > > #3 0x4027088f in Perl_sv_free () from /usr/lib/libperl.so.5.6 > > #4 0x40274d6f in Perl_sv_vcatpvfn () from /usr/lib/libperl.so.5.6 > > #5 0x4026a378 in Perl_sv_add_arena () from /usr/lib/libperl.so.5.6 > > #6 0x4026a434 in Perl_sv_clean_all () from /usr/lib/libperl.so.5.6 > > #7 0x40219b75 in perl_destruct () from /usr/lib/libperl.so.5.6 > > #8 0x401bbb77 in perl_shutdown (s=0x0, p=0x0) at mod_perl.c:294 > > #9 0x401bc507 in mp_dso_unload (data=0x8094bdc) at mod_perl.c:489 > > #10 0x08050c39 in run_cleanups (c=0x80a06cc) at alloc.c:1713 > > #11 0x0804f2d5 in ap_clear_pool (a=0x8094bdc) at alloc.c:538 > > #12 0x08060bfc in standalone_main (argc=6, argv=0xbffffac4) at > http_main.c:5058 > > #13 0x080615cc in main (argc=6, argv=0xbffffac4) at http_main.c:5448 > > > > The test.pl script works fine by it's self. Turning on full PERL > > debugging/tracing yields that the actual script has fully finished, and > > that it's in the tear down of the actualy perl stuff that this failure > > is coming from. Not from the script per se. But it is the script that > > is causing this problem. Commenting out the connect and disconnect > > lines causes the server to startup and function just fine. > > > > So I'm not quite sure what to do. I know I can get my entire system > > working if I don't make the calls to Informix at startup (it appears > > it's purely the connect that causes the error (whether it's a good > > connect or not, I tried giving it a bogus password, and it still > > crashes)), but well that's kind of a pain in the butt. > > > > So if anyone has ANY clues, it would be sincerely appreciated, as I need > > sleep, and I also would love to get this working. > > > > Thanks a ton in advance. > > > > Greg > > > > > > -- > > Greg Rumple > > [EMAIL PROTECTED] > -- Greg Rumple [EMAIL PROTECTED]
