DBD::Oracle 1.19 using instantclient 10.1.0.5 crashes under

I am experiencing a problem with DBD::Oracle 1.19, when building
against the Oracle "Instant Client" libraries version 10.1.0.5,
with perl 5.8.8 on an Ubuntu "Edgy Eft" system.

Everything works correctly when i use DBD::Oracle in perl scripts
executed by /usr/bin/perl. However, when i attempt to run this
same code from apache-mod_perl, apache crashes.

I am using the distro's apache:

$ /usr/sbin/apache -V
Server version: Apache/1.3.34 (Ubuntu)
Server built: Oct 25 2006 09:16:15
Server's Module Magic Number: 19990320:18
Server compiled with....
-D EAPI
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FCNTL_SERIALIZED_ACCEPT
-D HAVE_SYSVSEM_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D DYNAMIC_MODULE_LIMIT=64
-D HARD_SERVER_LIMIT=4096
-D HTTPD_ROOT="/usr"
-D SUEXEC_BIN="/usr/lib/apache/suexec"
-D DEFAULT_PIDLOG="/var/run/apache.pid"
-D DEFAULT_SCOREBOARD="/var/run/apache.scoreboard"
-D DEFAULT_LOCKFILE="/var/run/apache.lock"
-D DEFAULT_ERRORLOG="/var/log/apache/error.log"
-D TYPES_CONFIG_FILE="/etc/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache/httpd.conf"
-D ACCESS_CONFIG_FILE="/etc/apache/access.conf"
-D RESOURCE_CONFIG_FILE="/etc/apache/srm.conf"

This apache dumps core with the following stack trace:

Core was generated by `/usr/sbin/apache -d /home/sean/Work/cvs
-f /home/sean/Work/cvs/etc/apache/httpd'.
Program terminated with signal 11, Segmentation fault.
#0 0x4000887b in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
(gdb) where
#0 0x4000887b in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#1 0x40008c47 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#2 0x4000c942 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#3 0x40011d40 in _dl_make_stack_executable () from /lib/ld-linux.so.2
#4 0x40d119a3 in kpummfpg () from /usr/local/oracle/libclntsh.so.10.1
#5 0x40d4c805 in kghfrempty () from /usr/local/oracle/libclntsh.so.10.1
#6 0x40d42399 in kghgex () from /usr/local/oracle/libclntsh.so.10.1
#7 0x40d44392 in kghfnd () from /usr/local/oracle/libclntsh.so.10.1
#8 0x40d459dd in kghalo () from /usr/local/oracle/libclntsh.so.10.1
#9 0x40d42407 in kghgex () from /usr/local/oracle/libclntsh.so.10.1
#10 0x40d44392 in kghfnd () from /usr/local/oracle/libclntsh.so.10.1
#11 0x40d459dd in kghalo () from /usr/local/oracle/libclntsh.so.10.1
#12 0x4094a357 in kpuhhaloc () from /usr/local/oracle/libclntsh.so.10.1
#13 0x4090925d in kpughndl0 () from /usr/local/oracle/libclntsh.so.10.1
#14 0x40989ebb in OCIHandleAlloc ()
from /usr/local/oracle/libclntsh.so.10.1
#15 0x40741e93 in ora_db_login6 ()
from /usr/local/lib/perl/5.8.8/auto/DBD/Oracle/Oracle.so
#16 0x40736073 in XS_DBD__Oracle__db__login ()
from /usr/local/lib/perl/5.8.8/auto/DBD/Oracle/Oracle.so
#17 0x405f0af2 in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#18 0x405ef39f in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#19 0x40591a8c in Perl_magicname () from /usr/lib/libperl.so.5.8
#20 0x40592536 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#21 0x406c867f in XS_DBI_dispatch ()
from /usr/local/lib/perl/5.8.8/auto/DBI/DBI.so
#22 0x405f0af2 in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#23 0x405ef39f in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#24 0x40591a8c in Perl_magicname () from /usr/lib/libperl.so.5.8
#25 0x40592536 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#26 0x406c867f in XS_DBI_dispatch ()
from /usr/local/lib/perl/5.8.8/auto/DBI/DBI.so
#27 0x405f0af2 in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#28 0x405ef39f in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#29 0x40591a8c in Perl_magicname () from /usr/lib/libperl.so.5.8
#30 0x40592697 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#31 0x40527150 in perl_call_handler ()
from /usr/lib/apache/1.3/mod_perl.so
#32 0x40527944 in perl_run_stacked_handlers ()
from /usr/lib/apache/1.3/mod_perl.so
#33 0x40529637 in perl_handler () from /usr/lib/apache/1.3/mod_perl.so
#34 0x0805717b in ap_invoke_handler ()

I am surprised to see a crash in dl_make_stack_executable().
I have not been able to ascertain whether this build of apache
makes the stack nonexecutable to begin with.

Any assistance or insight that the readers of this group can
contribute would be appreciated.

-SEan