Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Segmentation fault on RHEL4

8 views
Skip to first unread message

Stephen More

unread,
May 16, 2005, 5:25:31 PM5/16/05
to dbi-...@perl.org
I have compiled DBD-ODBC-1.13 on RedHat Enterprise Linux 4.

Failed 2/9 test scripts, 77.78% okay. 6/137 subtests failed, 95.62% okay.
Good enough for me so I installed it.

I am using unixODBC-2.2.9-. connecting with isql is fine:
$isql mysql1 root

Yet a simple perl script:
#!/usr/bin/perl -w

use strict;
use DBD::ODBC;
DBI->trace( 1000 );
my( $dbh ) = DBI->connect( "dbi:ODBC:mysql1", "root" );

creates a Segmentation fault...

$ ./odbc.pl
DBI 1.40-ithread dispatch trace level set to 1000 (in pid 9488)
-> DBI->connect(dbi:ODBC:mysql1, root, ****)
-> DBI->install_driver(ODBC) for linux perl=5.008005 pid=9488
ruid=501 euid=501
install_driver: DBD::ODBC version 1.13 loaded from
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/DBD/ODBC.pm
New DBI::dr (for DBD::ODBC::dr, parent=, id=)
dbih_setup_handle(DBI::dr=HASH(0x8d95808)=>DBI::dr=HASH(0x8df7e78),
DBD::ODBC::dr, 0, Null!)
dbih_make_com(Null!, 0, DBD::ODBC::dr, 92, 0) thr#8c99008
dbih_setup_attrib(DBI::dr=HASH(0x8df7e78), Err, Null!)
SCALAR(0x8cb4a14) (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x8df7e78), State, Null!)
SCALAR(0x8cba338) (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x8df7e78), Errstr, Null!)
SCALAR(0x8cba314) (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x8df7e78), TraceLevel, Null!) 0
(already defined)
dbih_setup_attrib(DBI::dr=HASH(0x8df7e78), FetchHashKeyName,
Null!) 'NAME' (already defined)
<- install_driver= DBI::dr=HASH(0x8d95808)
>> default_user DISPATCH (DBI::dr=HASH(0x8d95808) rc1/3 @4 g1 ima1
pid#9488) at /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm
line 572 via ./odbc2.pl line 9
-> default_user in DBD::_::dr for DBD::ODBC::dr
(DBI::dr=HASH(0x8d95808)~0x8df7e78 'root' undef HASH(0x8d610a0))
thr#8c99008
<- default_user= ( 'root' undef ) [2 items] at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
572 via ./odbc2.pl line 9
>> connect DISPATCH (DBI::dr=HASH(0x8d95808) rc2/3 @5 g0 ima1
pid#9488) at /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm
line 590
-> connect for DBD::ODBC::dr (DBI::dr=HASH(0x8d95808)~0x8df7e78
'mysql1' 'root' **** HASH(0x8df9084)) thr#8c99008
New DBI::db (for DBD::ODBC::db, parent=DBI::dr=HASH(0x8df7e78), id=)
dbih_setup_handle(DBI::db=HASH(0x8df7e3c)=>DBI::db=HASH(0x8df90d8),
DBD::ODBC::db, 8d92f38, Null!)
dbih_make_com(DBI::dr=HASH(0x8df7e78), 8df8460, DBD::ODBC::db,
224, 0) thr#8c99008
dbih_setup_attrib(DBI::db=HASH(0x8df90d8), Err,
DBI::dr=HASH(0x8df7e78)) SCALAR(0x8d99280) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x8df90d8), State,
DBI::dr=HASH(0x8df7e78)) SCALAR(0x8d992e0) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x8df90d8), Errstr,
DBI::dr=HASH(0x8df7e78)) SCALAR(0x8d992b0) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x8df90d8), TraceLevel,
DBI::dr=HASH(0x8df7e78)) 0 (already defined)
dbih_setup_attrib(DBI::db=HASH(0x8df90d8), FetchHashKeyName,
DBI::dr=HASH(0x8df7e78)) 'NAME' (already defined)
dbih_setup_attrib(DBI::db=HASH(0x8df90d8), HandleError,
DBI::dr=HASH(0x8df7e78)) undef (not defined)
Driver connect 'mysql1', 'root', 'xxxx'
SQLDriverConnect failed:
SQLConnect 'mysql1', 'root'
Connected to: MySQL
SQLGetFunctions - SQL_MoreResults supported: 1
<- connect= DBI::db=HASH(0x8df7e3c) at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
590
>> STORE DISPATCH (DBI::db=HASH(0x8df90d8) rc2/1 @3 g0
ima41c pid#9488) at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
633
-> STORE for DBD::ODBC::db (DBI::db=HASH(0x8df90d8)~INNER
'PrintError' 1) thr#8c99008
DBD::ODBC unsupported attribute passed (PrintError)
STORE DBI::db=HASH(0x8df90d8) 'PrintError' => 1
<- STORE= 1 at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
633
>> STORE DISPATCH (DBI::db=HASH(0x8df90d8) rc2/1 @3 g0
ima41c pid#9488) at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
633
-> STORE for DBD::ODBC::db (DBI::db=HASH(0x8df90d8)~INNER
'AutoCommit' 1) thr#8c99008
<- STORE= 1 at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
633
>> STORE DISPATCH (DBI::db=HASH(0x8df90d8) rc2/1 @3 g0
ima41c pid#9488) at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
636
-> STORE for DBD::ODBC::db (DBI::db=HASH(0x8df90d8)~INNER
'Username' 'root') thr#8c99008
DBD::ODBC unsupported attribute passed (Username)
STORE DBI::db=HASH(0x8df90d8) 'Username' => 'root'
<- STORE= 1 at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
636
<- connect= DBI::db=HASH(0x8df7e3c)
>> STORE DISPATCH (DBI::db=HASH(0x8df90d8) rc2/1 @3 g0
ima41c pid#9488) at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
650 via ./odbc2.pl line 9
-> STORE for DBD::ODBC::db (DBI::db=HASH(0x8df90d8)~INNER
'dbi_connect_closure' CODE(0x8df7d88)) thr#8c99008
DBD::ODBC unsupported attribute passed (dbi_connect_closure)
STORE DBI::db=HASH(0x8df90d8) 'dbi_connect_closure' => CODE(0x8df7d88)
<- STORE= 1 at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line
650 via ./odbc2.pl line 9
>> DESTROY DISPATCH (DBI::db=HASH(0x8df7e3c) rc1/1 @1 g0 ima4 pid#9488)
<> DESTROY ignored for outer handle DBI::db=HASH(0x8df7e3c) (inner
DBI::db=HASH(0x8df90d8))
>> DESTROY DISPATCH (DBI::db=HASH(0x8df90d8) rc1/1 @1 g0 ima4 pid#9488)
-> DESTROY for DBD::ODBC::db (DBI::db=HASH(0x8df90d8)~INNER) thr#8c99008
Segmentation fault


What have I done wrong ?

-Steve More

Martin J. Evans

unread,
May 17, 2005, 4:45:30 AM5/17/05
to dbi-...@perl.org
Search this list for similar issue I previously replied to.

You are probably getting this because you have mixed Perl, unixODBC, MySQL
where some were built with -pthread and some were not. What seems to happen is
that some internal structure used by dlopen/dlclose is different when built
threaded or not (on some Linuxes/glibcs).

Try adding DontDLClose = 1 to the driver entry in odbcinst.ini.

Try rebuilding unixODBC and MySQL with -pthread to make them all the same.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development

Stephen More

unread,
May 17, 2005, 4:53:12 PM5/17/05
to Martin J. Evans, dbi-...@perl.org
> You are probably getting this because you have mixed Perl, unixODBC, MySQL
> where some were built with -pthread and some were not.

Can this be proven with ldd ? It looks like all are linked with libpthread.so.0

$ ldd /usr/bin/perl | grep -i pthread
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00a65000)
$ ldd /usr/lib/libodbc.so.1.0.0 | grep -i thread
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00a65000)
$ ldd /usr/lib/libmyodbc3.so | grep -i pthread
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00dd3000)
$ ldd /opt/ibm/iSeriesAccess/lib/libcwbodbc.so | grep -i pthread
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x005f4000)
$ ldd /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/auto/DBD/ODBC/ODBC.so
| grep -i pthread
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00c27000)


>What seems to happen is
> that some internal structure used by dlopen/dlclose is different when built
> threaded or not (on some Linuxes/glibcs).
>
> Try adding DontDLClose = 1 to the driver entry in odbcinst.ini.

This did not seem to help.

> Try rebuilding unixODBC and MySQL with -pthread to make them all the same.

I'll give that a shot.

-Steve More

Martin J. Evans

unread,
May 18, 2005, 3:57:25 AM5/18/05
to dbi-...@perl.org
Stephen,

The problem as you described it certainly looked like the issue with code
compiled with -pthread and without but given your results perhaps not. At
Easysoft, we see this issue of mixed apps/drivers/unixODBC fairly requently on
Linux but DontDLClose nearly always sorts it out.

There are two things you can do:

1. turn unixODBC tracing on to see what is happening. You do that by adding:

[ODBC]
TraceFile = /tmp/sql.log
Trace = Yes

to your odbcinst.ini file.

2. Run a simple Perl script connecting under gdb to see where it fails:

gdb /usr/bin/perl (or wherever your Perl is)
run -MDBI -e 'my $dbh = DBI->connect("dbi:ODBC:xxx", "user", "pass");'

When it crashes enter bt for a back trace.

Of course to do this you'd need to install DBI and DBD::ODBC or look at the
make test to see how to run when DBD::ODBC is not installed.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development

Stephen More

unread,
May 19, 2005, 7:21:36 AM5/19/05
to Martin J. Evans, dbi-...@perl.org
Here is the info from my bt:

(gdb) run -MDBI -e 'my $dbh = DBI->connect("dbi:ODBC:mysql1", "root" );'
Starting program: /usr/bin/perl -MDBI -e 'my $dbh =
DBI->connect("dbi:ODBC:mysql1", "root" );'
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)..
.(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...[Thread debugging using libth
read_db enabled]
[New Thread -1208035648 (LWP 13126)]
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208035648 (LWP 13126)]
0x00267115 in my_SQLFreeConnect () from /usr/lib/libmyodbc3.so
(gdb) bt
#0 0x00267115 in my_SQLFreeConnect () from /usr/lib/libmyodbc3.so
#1 0x002673e9 in SQLFreeHandle () from /usr/lib/libmyodbc3.so
#2 0x002370a6 in odbc_db_disconnect (dbh=0x843bd7c,
imp_dbh=0x8597188) at dbdimp.c:845
#3 0x0022d3ec in XS_DBD__ODBC__db_DESTROY (my_perl=0x843b008,
cv=0x84f93b8) at ODBC.xsi:352
#4 0x00c497a2 in XS_DBI_dispatch () from
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/DBI.so
#5 0x07ec79d2 in Perl_pp_entersub () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#6 0x07e55b09 in Perl_get_cv () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#7 0x07e5be67 in Perl_call_sv () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#8 0x07ecabe7 in Perl_sv_clear () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#9 0x07ecb4d4 in Perl_sv_free () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#10 0x07ecaf14 in Perl_sv_clear () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#11 0x07ecb4d4 in Perl_sv_free () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#12 0x07eb1a75 in Perl_mg_free () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#13 0x07ecb07e in Perl_sv_clear () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#14 0x07ecb4d4 in Perl_sv_free () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#15 0x07ecaf14 in Perl_sv_clear () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#16 0x07ecb4d4 in Perl_sv_free () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#17 0x07ef089c in Perl_free_tmps () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#18 0x07e5cc9d in perl_run () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#19 0x080493a2 in main ()
(gdb)


Here is the info from ODBC tracing.


[ODBC][13126][__handles.c][421]
Exit:[SQL_SUCCESS]
Environment = 0x859a550
[ODBC][13126][SQLSetEnvAttr.c][182]
Entry:
Environment = 0x859a550
Attribute = SQL_ATTR_ODBC_VERSION
Value = 0x3
StrLen = -6
[ODBC][13126][SQLSetEnvAttr.c][349]
Exit:[SQL_SUCCESS]
[ODBC][13126][SQLAllocHandle.c][345]
Entry:
Handle Type = 2
Input Handle = 0x859a550
[ODBC][13126][SQLAllocHandle.c][463]
Exit:[SQL_SUCCESS]
Output Handle = 0x859aae0
[ODBC][13126][SQLDriverConnect.c][666]
Entry:
Connection = 0x859aae0
Window Hdl = (nil)
Str In = [mysql1][length = 6]
Str Out = 0xbfe42480
Str Out Max = 2048
Str Out Ptr = 0xbfe4247e
Completion = 0
[ODBC][13126][SQLDriverConnect.c][998]Error: IM002
[ODBC][13126][SQLError.c][424]
Entry:
Connection = 0x859aae0
SQLState = 0xbfe42410
Native = 0xbfe42208
Message Text = 0xbfe42210
Buffer Length = 511
Text Len Ptr = 0xbfe4220e
[ODBC][13126][SQLError.c][461]
Exit:[SQL_SUCCESS]
SQLState = IM002
Native = 0xbfe42208 -> 0
Message Text = [[unixODBC][Driver Manager]Data
source name not found, and no default driver specified]
[ODBC][13126][SQLError.c][424]
Entry:
Connection = 0x859aae0
SQLState = 0xbfe42410
Native = 0xbfe42208
Message Text = 0xbfe42210
Buffer Length = 511
Text Len Ptr = 0xbfe4220e
[ODBC][13126][SQLError.c][461]
Exit:[SQL_NO_DATA]
[ODBC][13126][SQLConnect.c][3494]
Entry:
Connection = 0x859aae0
Server Name = [mysql1][length = 6]
User Name = [root][length = 4]
Authentication = [][length = 0]
UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

[ODBC][13126][SQLConnect.c][4068]
Exit:[SQL_SUCCESS]

Stephen More

unread,
May 19, 2005, 7:31:07 AM5/19/05
to Martin J. Evans, dbi-...@perl.org
> > 2. Run a simple Perl script connecting under gdb to see where it fails:
> >
> > gdb /usr/bin/perl (or wherever your Perl is)
> > run -MDBI -e 'my $dbh = DBI->connect("dbi:ODBC:xxx", "user", "pass");'
> >
> > When it crashes enter bt for a back trace.

Here is a backtrace using a different driver:

(gdb) run -MDBI -e 'my $dbh = DBI->connect("dbi:ODBC:as400");'


Starting program: /usr/bin/perl -MDBI -e 'my $dbh =

DBI->connect("dbi:ODBC:as400");'


(no debugging symbols found)...(no debugging symbols found)...(no

debugging symbols found)...(no debugging symbols found)...(no


debugging symbols found)...(no debugging symbols found)...(no

debugging symbols found)...[Thread debugging using libthread_db
enabled]
[New Thread -1208035648 (LWP 13219)]


(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread -1208035648 (LWP 13219)]
0x00185084 in htoobj::htoobj () from /opt/ibm/iSeriesAccess/lib/libcwbodbc.so
(gdb) bt
#0 0x00185084 in htoobj::htoobj () from
/opt/ibm/iSeriesAccess/lib/libcwbodbc.so
#1 0x00176c9d in SQLFreeHandle () from /opt/ibm/iSeriesAccess/lib/libcwbodbc.so
#2 0x00d9e4db in odbc_db_login6 (dbh=0x8409b2c, imp_dbh=0x84160f0,
dbname=0x832a740 "as400", uid=0x83f4ad8 "", pwd=0x8377ce8 "",
attr=0x8409afc) at dbdimp.c:662
#3 0x00d927fe in XS_DBD__ODBC__db__login (my_perl=0x82ba008,
cv=0x836ff84) at ODBC.xsi:92
#4 0x07ec79d2 in Perl_pp_entersub () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#5 0x07eaadbd in Perl_runops_debug () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#6 0x07e55ae6 in Perl_get_cv () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#7 0x07e5bc3e in Perl_call_sv () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#8 0x0032faaf in XS_DBI_dispatch () from
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/DBI.so
#9 0x07ec79d2 in Perl_pp_entersub () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#10 0x07eaadbd in Perl_runops_debug () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#11 0x07e5cc01 in perl_run () from
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
#12 0x080493a2 in main ()
(gdb)

And the odbc trace.

[ODBC][13219][SQLError.c][424]
Entry:
Connection = 0x8419678
SQLState = 0xbfe716d0
Native = 0xbfe714b8
Message Text = 0xbfe714d0
Buffer Length = 511
Text Len Ptr = 0xbfe714be
[ODBC][13219][SQLError.c][461]
Exit:[SQL_SUCCESS]
SQLState = 28000
Native = 0xbfe714b8 -> 8015
Message Text = [[unixODBC][IBM][iSeries Access
ODBC Driver]Communication link failure. comm rc=8015 - CWBSY1006 -
User ID
is invalid, Password l]
[ODBC][13219][SQLError.c][424]
Entry:
Connection = 0x8419678
SQLState = 0xbfe716d0
Native = 0xbfe714b8
Message Text = 0xbfe714d0
Buffer Length = 511
Text Len Ptr = 0xbfe714be
[ODBC][13219][SQLError.c][461]
Exit:[SQL_NO_DATA]
[ODBC][13219][SQLError.c][504]
Entry:
Environment = 0x84190e8
SQLState = 0xbfe716d0
Native = 0xbfe714b8
Message Text = 0xbfe714d0
Buffer Length = 511
Text Len Ptr = 0xbfe714be
[ODBC][13219][SQLError.c][541]
Exit:[SQL_NO_DATA]

Martin J. Evans

unread,
May 19, 2005, 8:12:36 AM5/19/05
to dbi-...@perl.org
Stephen,

As you will have noticed it falls over in my_SQLFreeConnect off SQLFreeHandle.

The interesting thing is I can't see unixODBC - I thought you were using
unixODBC?

Your trace (and the subsequent one don't seem to have unixODBC at all.
I'd expect to see unixODBC between DBD::ODBC and the driver - and yet you have
some unixODBC logging.

What i think is happening is that initially Perl loads unixODBC and
SQLAllocHandle symbols etc are located in unixODBC. When DBD::ODBC calls
SQLConnect, unixODBC loads the driver and then SQLxxx symbols are being
resolved in the driver instead of through unixODBC. As a result when DBD::ODBC
calls SQLFreeHandle the handle which DBD::ODBC has (and is unixODBC's handle)
is passed directly to mysql and mysql is not validating it (that bit is
arguably a bug in the driver).

See

http://www.easysoft.com/products/9999/faq_answer.phtml?ID=664&product=2002

You need to try PERL_DL_NONLAZY=1. If the problem goes away then see the rest
of the faq above for how to make sure unixODBC is built without the RTLD_GROUP
flag to dlopen.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development

Stephen More

unread,
May 19, 2005, 8:53:18 AM5/19/05
to Martin J. Evans, dbi-...@perl.org
> The interesting thing is I can't see unixODBC - I thought you were using
> unixODBC?

I think I am using it. ldd shows ODBC.so is linked to it:

$ ldd /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/auto/DBD/ODBC/ODBC.so
libodbc.so.1 => /usr/lib/libodbc.so.1 (0x00be6000)
libc.so.6 => /lib/tls/libc.so.6 (0x00111000)
libltdl.so.3 => /usr/lib/libltdl.so.3 (0x00f62000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0023a000)
/lib/ld-linux.so.2 (0x008f6000)
libdl.so.2 => /lib/libdl.so.2 (0x00eff000)
$ rpm --query -f /usr/lib/libodbc.so.1
unixODBC-2.2.9-1
$


> You need to try PERL_DL_NONLAZY=1. If the problem goes away then see the rest
> of the faq above for how to make sure unixODBC is built without the RTLD_GROUP
> flag to dlopen.

$ PERL_DL_NONLAZY=1
$ export PERL_DL_NONLAZY

That seems to have gotten rid of the Seg Fault !

I'll try to open up a bug with RedHat so this can be fixed in the distribution.

Thanks for all your help.
-Steve More

Martin J. Evans

unread,
May 19, 2005, 9:09:26 AM5/19/05
to dbi-...@perl.org
You can fix it for yourself by removing the RTLD_GROUP from unixODBC and
rebuilding it. See the FAQ I pointed you at.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development


On 19-May-2005 Stephen More wrote:

0 new messages