On 17/05/2011 14:54, eric.b...@barclayscapital.com wrote:
Just a quick update:
We switched back to using the FreeTDS driver under DBD::ODBC with the unixODBC
ODBC manager on Linux and the segfault problem went away.
That seems to suggest to me that it's a problem with the Easysoft driver, and
I've communicated this to the Easysoft team.
BTW, the Easysoft guys have been really terrific; responsive and knowledgeable.
A real pleasure to work with. Hopefully they can track down this bug.
Eric
Eric, I believe Easysoft support are sorting you out but as the problem
I believe you've hit potentially affects anyone else using an older
unixODBC on 64 bit platforms (or one without odbc_config) it is worth
mentioning it here.
Some background:
As many of you may know MS invented ODBC and then I believe handed it
over to X/Open. However, since then they have continued making changes
to the API. Before Windows 64 bit operating systems many ODBC APIs were
documented as taking or returning 32 bits values (and I mean that, not
int or long but documented as a 32 bit value which is strange for a C
API). When Windows 64 came along some APIs were changed to take an
SQLLEN/SQLULEN or a pointer to a SQLLEN/SQLULEN and an SQLLEN/SQLULEN
was defined as 32 bits on 32 bit operating systems and 64 bits on 64 bit
operating systems.
unixODBC and many ODBC drivers who were ahead of MS and building drivers
and driver managers for 64bit platforms could not know what MS were
going to do and they did not all make the same choice. Most stuck with
the API as it was which said 32 bit values. When MS changed ODBC to
introduce SQLLEN/SQLULEN it left some driver writers with a problem and
some had to produce 2 versions of their 64bit drivers - one using 32bit
values for some ODBC API parameters and one using 64bit values as there
were apps out there doing both.
These days unixODBC supports SQLLEN/SQLULEN and most drivers do and
unixODBC builds out the box with a 64bit SQLLEN/SQLULEN value. However,
this is ascertained at configure time and the header files which go with
unixODBC define SQLLEN/SQLULEN as 32bit or 64bit depending on whether
SIZEOF_LONG_INT is 32 or 64. DBD::ODBC looks for unixODBC's odbc_config
program which can be used to return the cc flags used to build unixODBC
and one of those flags is -DSIZEOF_LONG_INT=64. When DBD::ODBC finds
odbc_config it can add the right flags to the compiler when building
DBD::ODBC. When DBD::ODBC cannot find odbc_config (and it goes out of
its way to find it) it cannot know what to add to the compile line so
adds nothing. The result is that if you build DBD::ODBC on a 64bit
platform against unixODBC and odbc_config is not found SQLLEN/SQLULEN
will be 32 bits in size (incorrectly most of the time) and then APIs
like SQLRowCount which is passed a pointer to a SQLLEN will pass a
pointer to 4 bytes of space instead of 8 - thus corrupting the stack.
Now, whether your app (or DBD::ODBC or Perl) will segfault or when it
will segfault is just pot luck. It is not a driver bug but a bug in the
building of DBD::ODBC in a way incompatible with unixODBC.
As a side note to anyone looking after packages for Linux especially
like Ubuntu, Debian etc. Please, please upgrade unixODBC in your package
system to a newer version AND include odbc_config.
I am sorry this has caused you some problems. I will try and change
DBD::ODBC to issue a warning on 64 bit platforms if odbc_config is not
found but as few people pay much attention to the warnings I'm not sure
what good it will do.
Martin
-----Original Message-----
From: Berg, Eric: IT (NYK)
Sent: Friday, May 13, 2011 9:24 AM
To: 'Martin J. Evans'
Cc: dbi-users@perl.org
Subject: RE: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE
Thanks, Martin. I've been working with Richard on this for a few days and
he's been very helpful. Just not sure what's up here yet, but it was
recommended that I upgrade from the 1.3 version that we've got packaged
for use here at the bank to 1.4. We'll see if that makes a difference.
Many of the tests of DBD::ODBC are failing as well. I'm looking at that,
will upgrade and report my progress back to the list.
Thanks again.
-----Original Message-----
From: Martin J. Evans [mailto:martin.ev...@easysoft.com]
Sent: Friday, May 13, 2011 3:46 AM
To: Berg, Eric: IT (NYK)
Cc: dbi-users@perl.org
Subject: Re: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE
On 12/05/11 21:39, eric.b...@barclayscapital.com wrote:
Posted this in the Google Group, but not sure if it's going through,
so
I apologize for the duplicate if that's the case.
We're continuing with our struggles to get Perl working properly to
connect to MS SQL server, and have come up against a nasty bug that
results in segmentation faults when attempting to do a $dbh->do(...) to
set TEXTSIZE or truncate tables.
I'm running the following:
Perl : 5.012003 (x86_64-linux)
OS : linux (2.6.18-194.el5)
DBI : 1.616
DBD::ODBC : 1.29
EasySoft ODBC driver: 1.3
MS SQL Server 2008.
The following code generates a segfault when _ExecDirect is called at
DBD/ODBC.pm at line 396.
my $dbh = DBI->connect("dbi:ODBC:MSSQL", $user, $password) || die
"Error
connecting: $!";
$dbh->{LongReadLen} = 25000;
$sql = 'SELECT @@TEXTSIZE';
$sth = $dbh->prepare($sql);
$sth->execute();
print "SQL1: $sql:\n";
while ( @row = $sth->fetchrow_array ) {
print join( ", ", @row ), "\n";
}
$sql = 'set textsize 100';
print "SQL2: $sql:\n";
$sth = $dbh->do($sql);
warn 0;
And the output is:
$ ./set_text_size_test.pl
SQL1: SELECT @@TEXTSIZE:
-1
SQL2: set textsize 100:
Segmentation fault (core dumped)
and the "0" is never printed.
Running this in the Perl debugger shows me that it dies at DBD::ODBC
at
line 396, at which point it calls is an XS method defined in ODBC.c on
line 133:
void
_ExecDirect( dbh, stmt )
SV * dbh
SV * stmt
CODE:
{
STRLEN lna;
/*char *pstmt = SvOK(stmt) ? SvPV(stmt,lna) : "";*/
ST(0) = sv_2mortal(newSViv( (IV)dbd_db_execdirect( dbh, stmt ) )
);
}
Anyone have any idea what might be going on here?
Also, notice that the initial "SELECT @@TEXTSIZE" returns -1, which is
an unusual value.
Thanks for any help you might be able to provide.
Eric
Eric,
It does not segfault for me with DBD::ODBC 1.30_1 and our 1.4.18 driver.
I've passed your email onto Easysoft support and they should contact you
soon.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
_______________________________________________
This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intended recipient of
this e-mail, do not duplicate or redistribute it by any means. Please delete it
and any attachments and notify the sender that you have received it in error.
Unless specifically indicated, this e-mail is not an offer to buy or sell or a
solicitation to buy or sell any securities, investment products or other
financial product or service, an official confirmation of any transaction, or
an official statement of Barclays. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Barclays. This
e-mail is subject to terms available at the following link:
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the
foregoing. Barclays Capital is the investment banking division of Barclays
Bank PLC, a company registered in England (number 1026167) with its registered
office at 1 Churchill Place, London, E14 5HP. This email may relate to or be
sent from other members of the Barclays Group.
_______________________________________________
