You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Dau Hee <da...@yahoo.com> on 2001/11/18 06:56:50 UTC

[DBI] DBI->install_driver fails

Hi

I am running on Redhat 7.1 with Apache/1.3.22 and
mod_perl/1.26. My perl version is 5.6.1, my DBI is at
1.20, DBD-Oracle is at 1.12, ApacheDBI at 0.88 and
Oracle is at 8.1.7.0.1. I also use up2date to upgraded
my glibc to 2.2.4 from 2.2.2.

After the glibc upgrade, I cannot get Apache to run.
It dies immediately after starting. After playing
around with the configuration, I found that if I
comment out this line in startup.pl
DBI->install_driver("Oracle");
Apache will run just fine. No other configuration
options needs to be changed.

The odd thing about this is that when Apache dies,
nothing is printed on my console. Nothing is printed
to error_log as well(including the "resuming normal
operations" line that you normally see when you start
Apache). I also cannot find any core file(ulimit is
unlimited).

I recompiled everything again, meaning Apache,
mod_perl, DBI and DBD-Oracle and still no go.

I also tried to use gdb and this is what I get.
==========================================
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run -X
Starting program: /usr/sbin/httpd -X
[New Thread 1024 (LWP 14062)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 14062)]
0x403a388f in S_new_xpvmg () from
/etc/httpd/modules/libperl.so
(gdb) bt
#0  0x403a388f in S_new_xpvmg () from
/etc/httpd/modules/libperl.so
#1  0x403a3dc5 in Perl_sv_upgrade () from
/etc/httpd/modules/libperl.so
#2  0x403a7c4c in Perl_sv_magic () from
/etc/httpd/modules/libperl.so
#3  0x403954ce in Perl_mg_copy () from
/etc/httpd/modules/libperl.so
#4  0x40399608 in Perl_hv_store () from
/etc/httpd/modules/libperl.so
#5  0x40360a00 in S_init_postdump_symbols () from
/etc/httpd/modules/libperl.so
#6  0x4035dda5 in S_parse_body () from
/etc/httpd/modules/libperl.so
#7  0x4035d552 in perl_parse () from
/etc/httpd/modules/libperl.so
#8  0x4033f0e6 in perl_startup () from
/etc/httpd/modules/libperl.so
#9  0x40342e0d in perl_cmd_require () from
/etc/httpd/modules/libperl.so
#10 0x08054924 in invoke_cmd () at eval.c:41
#11 0x08054d3e in ap_handle_command () at eval.c:41
#12 0x08054dd1 in ap_srm_command_loop () at eval.c:41
#13 0x0805543e in ap_process_resource_config () at
eval.c:41
#14 0x08055d67 in ap_read_config () at eval.c:41
#15 0x0805fc4d in standalone_main () at eval.c:41
#16 0x080605bf in main () at eval.c:41
#17 0x4016e627 in __libc_start_main (main=0x8060220
<main>, argc=2,
    ubp_av=0xbffff8c4, init=0x804e278 <_init>,
fini=0x807d840 <_fini>,
    rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbffff8bc)
    at ../sysdeps/generic/libc-start.c:129
==========================================
Unfortunately I do not know what it means. 

I would think this is a problem with DBI and not
mod_perl but I am not sure. I also have no idea how to
fix this.

Without the install_driver line, I can still get my
entire website to operate as per normal.
Apache::DBI->connect_on_init still works without the
install_driver line. However I would really like to
use install_driver since I read in the mod_perl line
that this will reduce the memory usage in each child.

I appreciated any help rendered. Thannks.

Regards.







__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

Re: [DBI] DBI->install_driver fails

Posted by Dave Hodgkinson <da...@davehodgkinson.com>.
Ged Haywood <ge...@www2.jubileegroup.co.uk> writes:

> Hi there,
> 
> On Sat, 17 Nov 2001, Dau Hee wrote:
> 
> [snip,snip]
> > I also use up2date to upgraded my glibc to 2.2.4 from 2.2.2.
> 
> Why?  If it ain't broke, don't mend it.

Because RedHat will have fixed stuff. For some values of fixed.

I normally roll my own mod_perl Apaches, but I recently put RH7.1 on
my desktop and so far, the out-of-the box install and complete up2date
has been sweet.

My recommendation to our friend would be to make sure ALL the RPMs are
up to date - perl included. It might be a large update, but at least
everything will be in step.

When are we going for that beer, Ged? ;-)

-- 
David Hodgkinson, Wizard for Hire        http://www.davehodgkinson.com
Editor-in-chief, The Highway Star           http://www.deep-purple.com
Deep Purple Family Tree news                  http://www.slashrock.com
   Interim Technical Director, Web Architecture Consultant for hire

Re: [DBI] DBI->install_driver fails

Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,

On Sat, 17 Nov 2001, Dau Hee wrote:

[snip,snip]
> I also use up2date to upgraded my glibc to 2.2.4 from 2.2.2.

Why?  If it ain't broke, don't mend it.

> After the glibc upgrade, I cannot get Apache to run.

Not too surprising after upgrading glibc.  Have you recompiled Perl
itself?  Are you sure that you are using all the newly compiled code
(did you "make install")?

> The odd thing about this is that when Apache dies,
> nothing is printed on my console. Nothing is printed
> to error_log as well [snip]

This is not unusual when you get a segfault.

[snip]
> Program received signal SIGSEGV, Segmentation fault.
[snip]
> (gdb) bt
> #0  0x403a388f in S_new_xpvmg () from
> /etc/httpd/modules/libperl.so
[snip]
> Unfortunately I do not know what it means.

It means that mod_perl is crashing, a segmentation fault (segfault) is
when the process running your code tries to reach an area of memory to
which it is not allowed access.  Typically the code tries to call a
C function like free() for an area of memory which has already been
free()d, or maybe it runs off the end of an array (not a Perl array!)
or simply does an indexed write using an uninitialised pointer.  The
processor sends a signal (memory protection fault) to the operating
system, which kills the offending process.

You could try rebuilding mod_perl statically, see

http://perl.apache.org/guide

but if I'd rebuilt absolutely everything and I were sure that glibc
caused the problem I'd be tempted to go back to the earlier glibc.

> I would really like to use install_driver since I read in the
> mod_perl line that this will reduce the memory usage in each child.

If your machine is OK without it, don't worry about it too much.

73,
Ged.