Yes! Thanks for the clarification, Martin. Folks, I've had an opportunity to work with Martin and a few others on the EasySoft team on this and a few other problems, and I want you to know that they've been really helpful.
As a long-time OSS guy, I'm highly suspicious of proprietary software and the companies that "support" them, but EasySoft has been a great partner. They're knowledgeable, helpful and responsive, even considering that they're ...ehem...not in the US. This has been a really good experience, and I wanted to pass that on to the DBI community. Two thumbs up! Eric > -----Original Message----- > From: Martin J. Evans [mailto:martin.ev...@easysoft.com] > Sent: Friday, June 03, 2011 2:54 PM > To: dbi-users@perl.org > Subject: Re: DBD::ODBC Segfaults on SET TEXTSIZE and TRUNCATE TABLE > > 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 _______________________________________________ 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. _______________________________________________
