Compatibility of Vertica 7 ODBC driver with CentOS 5.0 using unixODBC 2.2.11 and PHP 5.1.6

Tod_Schumacher

We have been using the old Vertica 4.1.19 ODBC driver on CentOS 5 for several years while going through successive Vertica upgrades. Our current environment is: CentOS 5.9 (64-bit) Apache 2.2 PHP 5.1.6 unixODBC 2.2.11 Vertica 6.1.2 We would now like to move to Vertica 7 and upgrade to the latest ODBC driver. However, in this configuration PHP scripts running in Apache crash due to memory corruption when making ODBC calls to our Vertica DSN. Example from httpd error_log: *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev): 0x00002aaadd091a40 ***======= Backtrace: ========= /lib64/libc.so.6[0x2aaac41c245f] /lib64/libc.so.6(cfree+0x4b)[0x2aaac41c28bb] /etc/httpd/modules/libphp5.so(_efree+0xbc)[0x2aaacd65a99c] /usr/lib64/php/modules/odbc.so(zif_odbc_free_result+0xa2)[0x2aaad2653952] /etc/httpd/modules/libphp5.so[0x2aaacd69ea52] Also, running a trivial script outside apache also crashes: $conn = odbc_connect("VerticaDSN", "dbadmin", "dbadmin"); $rs = odbc_exec($conn, "SELECT COUNT(*) FROM ipmetrics_fact"); odbc_result_all($rs); odbc_close($conn); Through experimentation I have found that through upgrading to unixODBC64 2.2.14 and PHP 5.3.3 (available in CentOS 5.9 distribution) it appears to resolve the problem. Also, connecting to Vertica 7 with our Vertica DSN via "isql" and from C++ works fine. I think the problem may be that unixODBC 2.2.11 is incompatible due to a change in the ODBC specification where SQLLEN was changed from 4 to 8 bytes? However, there are a lot of revisions in PHP 5.3.3 and the code churn this would cause us in the short term is too much to take on right now. So my immediate problem is that I would like to find out if there is a simpler solution to get the Vertica 7 ODBC driver to work within our current environment with unixODBC 2.2.11 and PHP 5.1.6, or any alternative with less churn than going to PHP 5.3.3? Any help or tips is appreciated. /etc/odbc.ini: [Data Sources] VerticaDSN = "Capture_Database" [VerticaDSN] Description = "MTP Capture DB" Driver = /opt/vertica/lib64/libverticaodbc.so Database = capture ServerName = localhost UID = dbadmin PWD = Port = 5433 Locale = en_US /etc/vertica.ini [Driver] Locale = en_US DriverManagerEncoding=UTF-8 ODBCInstLib=/usr/lib64/libodbcinst.so.1 ErrorMessagesPath=/opt/vertica/lib64 LogLevel=6 LogPath=/opt/NetQoS/logs LogNameSpace= NOTE: I have also tried UTF-16 encoding with no apparent behavior change.

[Deleted User]

Hi Tod,

I can't speak more broadly to your question (hopefully others can); but I do know that the SQLLEN change that you note was a major change and is something that causes compatibility issues (read: crashes exactly like what you are seeing) for users of older versions of unixODBC.  The workaround is to upgrade unixODBC versions, or to use iODBC.  See our Supported Platforms document* for details on what versions work / are supported.

It's great to hear that Vertica has been working for you for so many versions!  For better or for worse, our client drivers underwent a major overhaul in version 5.1, including a few backwards-incompatible changes.  (There were some significant warts in our old drivers; it was decided that we needed to clean them up and present a consistent, standards-compliant interface.)  So if you're jumping all the way from 4.1 to 7.x, you may unfortunately find some bumps along the way...

Adam

* https://my.vertica.com/docs/7.0.x/PDF/HP_Vertica_7.0.x_Supported_Platforms.pdf

Tod_Schumacher

Thanks, Adam. I think you have answered my question. I looked at the Supported Platforms doc and it does in that one place directly state that unixODBC 2.2.14 is required. I had missed this. On CentOS 5 this package is named unixODBC64. I had looked at the Programmer's Guide, but the requirement for 2.2.14 was not stated explicitly there. Unfortunately, upgrading to 2.2.14 also requires upgrading to PHP 5.3.3 (modules named PHP53 on CentOS 5), which will require significant code changes in our product. But at least this clears up understanding of this issue for us. Thanks!