You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Greg Rumple <gr...@zaphon.llamas.net> on 2002/07/28 07:25:55 UTC
okay, I give, I'm stumped
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
grumple@zaphon.llamas.net
Re: $r->dir_config->(un)set issue...
Posted by Stas Bekman <st...@stason.org>.
simran wrote:
> Does that mean that
>
> $r->dir_config is not the same as $r->server->dir_config ?
not the same, $r->dir_config is a merge of the Location section setting
with Server/Vhost settings, $r->server->dir_config is only for
Server/Vhost settings.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: $r->dir_config->(un)set issue...
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> The following pices of code do not work:
>
> -----------------------------------------------------
> code sample 1
> --------------
>
> 1. sub handler {
> 2. my $r = instance Apache::Request(shift);
> 3.
> 4. $r->dir_config(MyVar => undef);
> 5.
> 6. $r->dir_config->unset("MyVar");
> 7.
> 8. $r->dir_config->set(MyVar => undef);
> 9.
> 10. }
>
>
> None of lines 4, 6 or 8 actually unset the variable.
did you try $r->server->dir_config->unset("MyVar") as well?
the dir_config table is a bit strange, since it merges per-server and
per-directory configurations at runtime - from what I remember when
playing with this last time, if you remove it from the per-dir config
but you set it on a per-server config (which sounds like what you are
doing) it will be perpetually re-populated on access to the per-dir
config. so, you may need to wipe both dir_config tables clean in
order to really unset the variable from your handler.
HTH
--Geoff
Re: $r->dir_config->(un)set issue...
Posted by simran <si...@cse.unsw.edu.au>.
On Wed, 2002-07-31 at 21:33, Geoffrey Young wrote:
>
>
> simran wrote:
>
> > Does that mean that
> >
> > $r->dir_config is not the same as $r->server->dir_config ?
> >
> > A PerlUnsetVar would indeed be very handy... as would PerlUnsetEnv :-)
>
> I looked into implementing that the last time it came up but IIRC it
> would take redoing the merge routines - from what I remember I got
> PerlUnsetVar to work at conf parse time, but it ended up being
> repopulated at request time when the directory merger ran (to merge
> $r->server->dir_config and $r->dir_config I think).
>
> calling unset() manually is probably your best bet.
>
I wouldn't mind using that, except that it does not work for me... (i
have copied a part of the original message below as that got snipped...)
I have a situation where it is convinent for me to define a global
"PerlSetVar" in my httpd.conf and then unset it for particular virtual
hosts.
I used to use the following configuration successfully:
----------------------------------------------------
httpd.conf
----------
<Perl>
use Apache::Server;
Apache->server->dir_config->unset("MyVar");
</Perl>
-----------------------------------------------------
That stopped working for me ever since we compiled
Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
Has anyone else had the same issue?
On a similar note:
The following pices of code do not work:
-----------------------------------------------------
code sample 1
--------------
1. sub handler {
2. my $r = instance Apache::Request(shift);
3.
4. $r->dir_config(MyVar => undef);
5.
6. $r->dir_config->unset("MyVar");
7.
8. $r->dir_config->set(MyVar => undef);
9.
10. }
None of lines 4, 6 or 8 actually unset the variable.
A collegue tells me that if a "true" value (for the key MyVar) is not
passed to set then it ends up returning the value of MyVar - but then
how i want to set the value of MyVar to be false. I would have though
that unset/set would have specifically done what i told them to
unset/set rather than do fancy things with truth values...
Re: $r->dir_config->(un)set issue...
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
simran wrote:
> Does that mean that
>
> $r->dir_config is not the same as $r->server->dir_config ?
>
> A PerlUnsetVar would indeed be very handy... as would PerlUnsetEnv :-)
I looked into implementing that the last time it came up but IIRC it
would take redoing the merge routines - from what I remember I got
PerlUnsetVar to work at conf parse time, but it ended up being
repopulated at request time when the directory merger ran (to merge
$r->server->dir_config and $r->dir_config I think).
calling unset() manually is probably your best bet.
--Geoff
Re: $r->dir_config->(un)set issue...
Posted by simran <si...@cse.unsw.edu.au>.
Does that mean that
$r->dir_config is not the same as $r->server->dir_config ?
A PerlUnsetVar would indeed be very handy... as would PerlUnsetEnv :-)
On Wed, 2002-07-31 at 12:50, Stas Bekman wrote:
> s/$r->dir_config/$r->server->dir_config/?
>
> What's really needed is probably PerlUnSetEnv.
>
> simran wrote:
> > Hi All,
> >
> > I have a situation where it is convinent for me to define a global
> > "PerlSetVar" in my httpd.conf and then unset it for particular virtual
> > hosts.
> >
> > I used to use the following configuration successfully:
> >
> > ----------------------------------------------------
> > httpd.conf
> > ----------
> >
> > <Perl>
> > use Apache::Server;
> > Apache->server->dir_config->unset("MyVar");
> > </Perl>
> >
> > -----------------------------------------------------
> >
> > That stopped working for me ever since we compiled
> > Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
> >
> >
> > Has anyone else had the same issue?
> >
> > On a similar note:
> >
> > The following pices of code do not work:
> >
> > -----------------------------------------------------
> > code sample 1
> > --------------
> >
> > 1. sub handler {
> > 2. my $r = instance Apache::Request(shift);
> > 3.
> > 4. $r->dir_config(MyVar => undef);
> > 5.
> > 6. $r->dir_config->unset("MyVar");
> > 7.
> > 8. $r->dir_config->set(MyVar => undef);
> > 9.
> > 10. }
>
> s/$r->dir_config/$r->server->dir_config/?
>
> What's really needed is probably PerlUnSetEnv.
>
> > None of lines 4, 6 or 8 actually unset the variable.
> >
> > A collegue tells me that if a "true" value (for the key MyVar) is not
> > passed to set then it ends up returning the value of MyVar - but then
> > how i want to set the value of MyVar to be false. I would have though
> > that unset/set would have specifically done what i told them to
> > unset/set rather than do fancy things with truth values...
> >
> > Ideas anyone?
> >
> > simran.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
>
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
Re: $r->dir_config->(un)set issue...
Posted by Stas Bekman <st...@stason.org>.
simran wrote:
> Hi All,
>
> I have a situation where it is convinent for me to define a global
> "PerlSetVar" in my httpd.conf and then unset it for particular virtual
> hosts.
>
> I used to use the following configuration successfully:
>
> ----------------------------------------------------
> httpd.conf
> ----------
>
> <Perl>
> use Apache::Server;
> Apache->server->dir_config->unset("MyVar");
> </Perl>
>
> -----------------------------------------------------
>
> That stopped working for me ever since we compiled
> Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
>
>
> Has anyone else had the same issue?
>
> On a similar note:
>
> The following pices of code do not work:
>
> -----------------------------------------------------
> code sample 1
> --------------
>
> 1. sub handler {
> 2. my $r = instance Apache::Request(shift);
> 3.
> 4. $r->dir_config(MyVar => undef);
> 5.
> 6. $r->dir_config->unset("MyVar");
> 7.
> 8. $r->dir_config->set(MyVar => undef);
> 9.
> 10. }
s/$r->dir_config/$r->server->dir_config/?
What's really needed is probably PerlUnSetEnv.
> None of lines 4, 6 or 8 actually unset the variable.
>
> A collegue tells me that if a "true" value (for the key MyVar) is not
> passed to set then it ends up returning the value of MyVar - but then
> how i want to set the value of MyVar to be false. I would have though
> that unset/set would have specifically done what i told them to
> unset/set rather than do fancy things with truth values...
>
> Ideas anyone?
>
> simran.
>
>
>
>
>
>
>
>
>
>
>
>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
$r->dir_config->(un)set issue...
Posted by simran <si...@cse.unsw.edu.au>.
Hi All,
I have a situation where it is convinent for me to define a global
"PerlSetVar" in my httpd.conf and then unset it for particular virtual
hosts.
I used to use the following configuration successfully:
----------------------------------------------------
httpd.conf
----------
<Perl>
use Apache::Server;
Apache->server->dir_config->unset("MyVar");
</Perl>
-----------------------------------------------------
That stopped working for me ever since we compiled
Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
Has anyone else had the same issue?
On a similar note:
The following pices of code do not work:
-----------------------------------------------------
code sample 1
--------------
1. sub handler {
2. my $r = instance Apache::Request(shift);
3.
4. $r->dir_config(MyVar => undef);
5.
6. $r->dir_config->unset("MyVar");
7.
8. $r->dir_config->set(MyVar => undef);
9.
10. }
None of lines 4, 6 or 8 actually unset the variable.
A collegue tells me that if a "true" value (for the key MyVar) is not
passed to set then it ends up returning the value of MyVar - but then
how i want to set the value of MyVar to be false. I would have though
that unset/set would have specifically done what i told them to
unset/set rather than do fancy things with truth values...
Ideas anyone?
simran.
Re: okay, I give, I'm stumped
Posted by Greg Rumple <gr...@zaphon.llamas.net>.
I actually was successful at building apache/mod_perl static with DSO
support and not having to change the rest of the modules. It appears to
be working, so will continue to test further.
Greg
* Drew Taylor (drew@drewtaylor.com) [020728 22:19]:
> There are well written instructions in The Guide that show step by step how
> to roll a static mod_perl/php/ssl binary. And I've done it personally
> without much trouble, so it's easier than you might think. ;-) Here's the
> direct link:
> http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_php
>
> Drew
>
> At 07:59 PM 7/28/2002 -0700, Greg Rumple wrote:
> >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.
>
> ======================================================================
> Drew Taylor | Freelance web development using
> http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI
> mailto:drew@drewtaylor.com | Email jobs at drewtaylor.com
> ----------------------------------------------------------------------
> Netflix: Unlimited DVD rentals with NO LATE FEES for $19.95/mo.
> http://service.bfast.com/bfast/click?bfmid=27276611&siteid=39734327&bfpage=special
> ======================================================================
>
--
Greg Rumple
grumple@zaphon.llamas.net
Re: okay, I give, I'm stumped
Posted by Drew Taylor <dr...@drewtaylor.com>.
There are well written instructions in The Guide that show step by step how
to roll a static mod_perl/php/ssl binary. And I've done it personally
without much trouble, so it's easier than you might think. ;-) Here's the
direct link:
http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_php
Drew
At 07:59 PM 7/28/2002 -0700, Greg Rumple wrote:
>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.
======================================================================
Drew Taylor | Freelance web development using
http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI
mailto:drew@drewtaylor.com | Email jobs at drewtaylor.com
----------------------------------------------------------------------
Netflix: Unlimited DVD rentals with NO LATE FEES for $19.95/mo.
http://service.bfast.com/bfast/click?bfmid=27276611&siteid=39734327&bfpage=special
======================================================================
Re: okay, I give, I'm stumped
Posted by Greg Rumple <gr...@zaphon.llamas.net>.
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 (kyle@centralparksoftware.com) [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
> > grumple@zaphon.llamas.net
>
--
Greg Rumple
grumple@zaphon.llamas.net
Re: okay, I give, I'm stumped
Posted by Kyle Dawkins <ky...@centralparksoftware.com>.
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
> grumple@zaphon.llamas.net
Re: okay, I give, I'm stumped
Posted by Greg Rumple <gr...@zaphon.llamas.net>.
* David Kaufman (gigawatt@optonline.net) [020728 00:55]:
> again, just a shot in the dark, but why not try the more mod_perl specific
> Apache::DBI instead of plain ole DBI?
Okay I have tried this. I also edited the Apache/DBI.pm and enabled
both Apache::DBI and DBI debugging at level 2 so I could get a better
idea of what is going on before it dies. I also put a line at the top
of my perl file and the end of my perl file defining the begin and end.
Here's what I see before it dies.
DBI 1.21-nothread dispatch trace level set to 2
Note: perl is running without the recommended perl -w option
------------ BEGIN -----------
-> DBI->Apache::DBI::connect(dbi:Informix:test, test, ****)
-> DBI->install_driver(Informix) for linux perl=5.006001 pid=17059
ruid=1000 euid=1000
install_driver: DBD::Informix version 1.00.PC2 loaded from
/usr/local/lib/perl/5.6.1/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0x819f0a8)
<- FETCH= 'Informix' ('Name' from cache) at DBI.pm line 64
17059 Apache::DBI skipping connection during server startup,
read the docu !!
-> connect for DBD::Informix::dr (DBI::dr=HASH(0x819f0a8)~0x81f50a0
'test' 'test' **** HASH(0x817d044))
-->> DBD::Informix::dbd_ix_db_preset()
AutoCommit set to 1
<<-- DBD::Informix::dbd_ix_db_preset()
-->> DBD::Informix::dbd_ix_db_login()
CONNECT TO 'test' with user info
<<-- DBD::Informix::dbd_ix_db_login()
<- connect= DBI::db=HASH(0x81d4204) at DBI.pm line 83
-> STORE for DBD::Informix::db (DBI::db=HASH(0x81e1b68)~INNER
'PrintError' 1)
-->> DBD::Informix::dbd_ix_db_STORE_attrib()
<<-- DBD::Informix::dbd_ix_db_STORE_attrib()
<- STORE= 1 at DBI.pm line 513
-> STORE for DBD::Informix::db (DBI::db=HASH(0x81e1b68)~INNER
'AutoCommit' 1)
-->> DBD::Informix::dbd_ix_db_STORE_attrib()
<<-- DBD::Informix::dbd_ix_db_STORE_attrib()
<- STORE= 1 at DBI.pm line 513
<- connect= DBI::db=HASH(0x81d4204)
------------ END -----------
-> DESTROY for DBD::Informix::db (DBI::db=HASH(0x81e1b68)~INNER)
-->> DBD::Informix::dbd_ix_db_disconnect()
DBD::Informix::dbd_ix_db_disconnect -- delete statements
-->> DBD::Informix::dbd_ix_link_delchain()
<<-- DBD::Informix::dbd_ix_link_delchain()
DBD::Informix::dbd_ix_db_disconnect -- statements deleted
DISCONNECT (x_000000000)
DISCONNECT -- STATUS 0
<<-- DBD::Informix::dbd_ix_db_disconnect()
-->> DBD::Informix::dbd_ix_db_destroy()
<<-- DBD::Informix::dbd_ix_db_destroy()
<- DESTROY= undef
Than it cores, all new core dump.
#0 0x40260194 in Perl_share_hek () from /usr/lib/libperl.so.5.6
#1 0x4025e919 in Perl_hv_store () from /usr/lib/libperl.so.5.6
#2 0x4025e56a in Perl_hv_fetch () from /usr/lib/libperl.so.5.6
#3 0x4021fa44 in Perl_gv_fetchpv () from /usr/lib/libperl.so.5.6
#4 0x40225a1c in Perl_yylex () from /usr/lib/libperl.so.5.6
#5 0x402374f0 in Perl_yyparse () from /usr/lib/libperl.so.5.6
#6 0x4028bc49 in Perl_sv_compile_2op () from /usr/lib/libperl.so.5.6
#7 0x4028cf6c in Perl_pp_require () from /usr/lib/libperl.so.5.6
#8 0x40262411 in Perl_runops_standard () from /usr/lib/libperl.so.5.6
#9 0x4021ab2c in perl_call_sv () from /usr/lib/libperl.so.5.6
#10 0x4021a89e in perl_call_sv () from /usr/lib/libperl.so.5.6
#11 0x4021e1db in Perl_call_list () from /usr/lib/libperl.so.5.6
#12 0x4021de4f in Perl_call_list () from /usr/lib/libperl.so.5.6
#13 0x40242b92 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.6
#14 0x4023face in Perl_utilize () from /usr/lib/libperl.so.5.6
#15 0x4023829a in Perl_yyparse () from /usr/lib/libperl.so.5.6
#16 0x4028bc49 in Perl_sv_compile_2op () from /usr/lib/libperl.so.5.6
#17 0x4028cf6c in Perl_pp_require () from /usr/lib/libperl.so.5.6
#18 0x40262411 in Perl_runops_standard () from /usr/lib/libperl.so.5.6
#19 0x4021ab2c in perl_call_sv () from /usr/lib/libperl.so.5.6
#20 0x4021a89e in perl_call_sv () from /usr/lib/libperl.so.5.6
#21 0x4021e1db in Perl_call_list () from /usr/lib/libperl.so.5.6
#22 0x4021de4f in Perl_call_list () from /usr/lib/libperl.so.5.6
#23 0x40242b92 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.6
#24 0x4023face in Perl_utilize () from /usr/lib/libperl.so.5.6
#25 0x4023829a in Perl_yyparse () from /usr/lib/libperl.so.5.6
#26 0x4028bc49 in Perl_sv_compile_2op () from /usr/lib/libperl.so.5.6
#27 0x4028cf6c in Perl_pp_require () from /usr/lib/libperl.so.5.6
#28 0x40262411 in Perl_runops_standard () from /usr/lib/libperl.so.5.6
#29 0x4021ab2c in perl_call_sv () from /usr/lib/libperl.so.5.6
#30 0x4021a89e in perl_call_sv () from /usr/lib/libperl.so.5.6
#31 0x4021e1db in Perl_call_list () from /usr/lib/libperl.so.5.6
#32 0x4021de4f in Perl_call_list () from /usr/lib/libperl.so.5.6
#33 0x40242b92 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.6
#34 0x4023face in Perl_utilize () from /usr/lib/libperl.so.5.6
#35 0x4023829a in Perl_yyparse () from /usr/lib/libperl.so.5.6
#36 0x4028bc49 in Perl_sv_compile_2op () from /usr/lib/libperl.so.5.6
#37 0x4028cf6c in Perl_pp_require () from /usr/lib/libperl.so.5.6
#38 0x40262411 in Perl_runops_standard () from /usr/lib/libperl.so.5.6
#39 0x4021ab2c in perl_call_sv () from /usr/lib/libperl.so.5.6
#40 0x4021a89e in perl_call_sv () from /usr/lib/libperl.so.5.6
#41 0x4021e1db in Perl_call_list () from /usr/lib/libperl.so.5.6
#42 0x4021de4f in Perl_call_list () from /usr/lib/libperl.so.5.6
#43 0x40242b92 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.6
#44 0x4023face in Perl_utilize () from /usr/lib/libperl.so.5.6
#45 0x4023829a in Perl_yyparse () from /usr/lib/libperl.so.5.6
#46 0x4028bc49 in Perl_sv_compile_2op () from /usr/lib/libperl.so.5.6
#47 0x4028cf6c in Perl_pp_require () from /usr/lib/libperl.so.5.6
#48 0x40262411 in Perl_runops_standard () from /usr/lib/libperl.so.5.6
#49 0x4021ab2c in perl_call_sv () from /usr/lib/libperl.so.5.6
#50 0x4021acce in perl_eval_sv () from /usr/lib/libperl.so.5.6
#51 0x404856e4 in perl_require_module (name=0x404abd64 "Apache", s=0x8094c04) at perl_util.c:550
#52 0x4047e9d7 in perl_cmd_module (parms=0xbffff8fc, dummy=0x8096904, arg=0x82147fc "Apache::DBI") at perl_config.c:591
#53 0x08054e7d in invoke_cmd (cmd=0x404b3090, parms=0xbffff8fc, mconfig=0x8096904, args=0xbfffd872 "") at http_config.c:946
#54 0x08055301 in ap_handle_command (parms=0xbffff8fc, config=0x8095134, l=0xbfffd85c "PerlModule Apache::DBI") at http_config.c:1079
#55 0x0805539d in ap_srm_command_loop (parms=0xbffff8fc, config=0x8095134) at http_config.c:1093
#56 0x08055a69 in ap_process_resource_config (s=0x8094c04, fname=0x808d700 "/var/tmp/test.conf", p=0x8094bdc, ptemp=0x809f2fc) at http_config.c:1355
#57 0x080563bc in ap_read_config (p=0x8094bdc, ptemp=0x809f2fc, confname=0x808d700 "/var/tmp/test.conf") at http_config.c:1647
#58 0x08060c43 in standalone_main (argc=6, argv=0xbffffa64) at http_main.c:5158
#59 0x080615cc in main (argc=6, argv=0xbffffa64) at http_main.c:5558
So for grins, I than decided I would try postgres to just verify this is
an Informix issue.
I commented out the Informix lines in my startup perl script, and added
the 4 lines necessary to connect to a local postgres database, and sure
enough it works. Here's what the output looks like.
DBI 1.21-nothread dispatch trace level set to 2
Note: perl is running without the recommended perl -w option
------------ BEGIN -----------
->
DBI->Apache::DBI::connect(dbi:Pg:dbname=ftf;host=grumple;port=6110, ,
****)
-> DBI->install_driver(Pg) for linux perl=5.006001 pid=17070
ruid=1000 euid=1000
install_driver: DBD::Pg version 1.11 loaded from
/home/grumple/src/ftf.newshit/ext/lib/perl5/DBD/Pg.pm
<- install_driver= DBI::dr=HASH(0x819f0a8)
<- FETCH= 'Pg' ('Name' from cache) at DBI.pm line 64
17070 Apache::DBI skipping connection during server startup,
read the docu !!
-> connect for DBD::Pg::dr (DBI::dr=HASH(0x819f0a8)~0x81f656c
'dbname=ftf;host=grumple;port=6110' '' **** HASH(0x817d044))
pg_db_login
pg_db_login: conn_str = >dbname=ftf host=grumple port=6110<
<- connect= DBI::db=HASH(0x81f6530) at DBI.pm line 83
-> STORE for DBD::Pg::db (DBI::db=HASH(0x81f6518)~INNER 'PrintError'
1)
dbd_db_STORE
<- STORE= 1 at DBI.pm line 513
-> STORE for DBD::Pg::db (DBI::db=HASH(0x81f6518)~INNER 'AutoCommit'
1)
dbd_db_STORE
dbd_db_STORE: initialize AutoCommit to on
<- STORE= 1 at DBI.pm line 513
<- connect= DBI::db=HASH(0x81f6530)
------------ END -----------
-> DESTROY for DBD::Pg::db (DBI::db=HASH(0x81f6518)~INNER)
Database handle destroyed without explicit disconnect.
dbd_db_disconnect
dbd_db_destroy
<- DESTROY= undef
It seems to just look good, and work all dandy. Yet the Informix
driver just blows up horribly.
>
> > use DBD::Informix;
>
> i don't think you need this use statement at all. the DBI->connect() call
> should load the "correct" DBD Driver, for you, not that it *should* make any
> difference... but hey.
Me either, just put it in there just in case. Makes NO difference.
> i would certainly suggest adding:
>
> or die DBI::errstr;
>
> to that connect() call!
Yeah, was just throwing together a sample program. Not trying to put
together something to be "production" quality. :-)
>
> > $dbh->disconnect();
>
> um, okay but why disconnect at all, if you know the segfault is caused by
> the connect and/or disconnect calls? have you tries simply *not*
> disconnecting? one of The Features/Advantages of Apache::DBI (over plain
> ole DBI) is that disconnect calls simlpy destroy the connection *object*
> (the perl data structure) without actually disconnecting from the DB, and
> therby maintaining a pool of cached connections, and therby speeding things
> up nicely.
I have removed the disconnect, but it makes no difference as suspected.
I will note that once the server is started, it has 0 problems
communicating with Informix, it's only in this startup script that it
blows up badly.
--
Greg Rumple
grumple@zaphon.llamas.net
Re: okay, I give, I'm stumped
Posted by David Kaufman <gi...@optonline.net>.
"Greg Rumple" <gr...@zaphon.llamas.net> wrote:
> 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.
<conf snippage; test.pl containing:>
> BEGIN {
> unshift(@INC, qw(
> /home/grumple/src/test/lib/perl5
> /home/grumple/src/test/system/lib/perl5
> ));
> }
did you intend that this BEGIN block only execute at server-start time, not
for each script execution? if not, you might try replacing this with:
use lib qw(
/home/grumple/src/test/lib/perl5
/home/grumple/src/test/system/lib/perl5
);
> use DBI;
again, just a shot in the dark, but why not try the more mod_perl specific
Apache::DBI instead of plain ole DBI?
> use DBD::Informix;
i don't think you need this use statement at all. the DBI->connect() call
should load the "correct" DBD Driver, for you, not that it *should* make any
difference... but hey.
> ## 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);
i would certainly suggest adding:
or die DBI::errstr;
to that connect() call!
> $dbh->disconnect();
um, okay but why disconnect at all, if you know the segfault is caused by
the connect and/or disconnect calls? have you tries simply *not*
disconnecting? one of The Features/Advantages of Apache::DBI (over plain
ole DBI) is that disconnect calls simlpy destroy the connection *object*
(the perl data structure) without actually disconnecting from the DB, and
therby maintaining a pool of cached connections, and therby speeding things
up nicely.