On 03/06/2011 19:21, bergbrains wrote:
The resolution of this issue was to rebuild DBD::ODBC, using an
available odbc_config, which correctly informed the build that it
should use 64-bit, instead of its defaulting to 32-bit. That cleared
up all of these segfault issues.
I'm pleased to hear that.
Just to make this clear in the hope others don't fall into this problem...
unixODBC contains sql*.h header files which depend on configure. As a
result they contain things like:
#if (SIZEOF_LONG_INT == 4)
typedef unsigned long DWORD;
#else
typedef unsigned int DWORD;
#endif
there are other instances of this. configure sets SIZEOF_LONG_INT when
you configure and build unixODBC so all is well when you build unixODBC.
However, after you've built unixODBC and installed those sql*.h header
files any application built against unixODBC needs to have
SIZEOF_LONG_INT set the same as it was when unixODBC was built.
If you don't have an ancient version of unixODBC (and unfortunately,
some Linux distros in particular contain ancient versions of unixODBC)
you don't have the odbc_config program and DBD::ODBC looks for
odbc_config to run its --cflags argument which returns a list of defines
unixODBC was built with. If DBD::ODBC does not find odbc_config it has
no idea how unixODBC was built and so you can get a DBD::ODBC which has
some types expecting 4 bytes when in unixODBC they are 8 bytes (leading
to corruption). Now, I could just change DBD::ODBC to refuse to build in
this case but as few Linux distros contain anything other than an
ancient unixODBC I'd get inundated with people complaining it does not
build (on 32bit platforms) when in fact it makes little difference to
them and only affects 64bit platforms.
More recent versions (not that recent actually) of unixODBC contain
odbc_config and that should work. Even more recent versions of unixODBC
contain header files that require SIZEOF_LONG_INT to be defined or they
baulk.
I think this was all covered in previous posts but just to make sure.
Martin
On May 17, 2:06 pm, martin.ev...@easysoft.com ("Martin J. Evans")
wrote:
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-us...@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-us...@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
