Tag Archives: php

PHP segfaults with pdo_odbc and bound parameters on 64-bit platforms

The title says it all with this post: PHP segfaults with pdo_odbc on 64-bit platforms when using a query that has bound parameters (named, indexed/placeholder, bindParam(), and bindValue() in any combination).

I’ve submitted a pull request (which fails its Travis build due to 5.5.9 failing its Travis build) to keep this in the minds of the php maintainers as it’s a pretty severe problem for people using php in a more “corporate” environment (where postgres and mariadb/mysql aren’t as pervasive).

With our millions of records stored in MS SQL and iSeries DB2 UDB databases at my current employer – this is a huge problem. We’re basically confined to 32-bit environments unless we want to pay for an additional method to connect to the iSeries (IBM DB2 Connect) and even then we’d be reliant on the MS SQL ‘sqlsrv’ php driver which I’ve found to be incredibly slow with medium-sized or larger data sets.

This hasn’t been a huge problem yet for most people using Windows since IIS’ fastcgi support seems to be only 32-bit currently, but with the way Azure has been getting pushed and adopted I would assume that a demand for 64-bit fastcgi apps on Azure will be approaching soon.

php 5.5 32-bit on Azure x64

PHP 5.5 is pre-installed as 32-bit on a Microsoft Azure 64-bit “Standard” scaled “Website”.

While bugs for this issue have been outstanding for quite some time, I’ve compiled a version of pdo_odbc as a shared extension with the patches people have agreed upon. After taking a look at the history of pdo_odbc – my shared extension may work with php versions as far back as the last stable release of the 5.3 branch and has been compiled on Ubuntu 13.10 x64 (so it should work on most 64-bit Ubuntu/Debian derivatives that have glibc 2.14+) against the php 5.5.9 stable source.

The extension is relatively simple to toss in to your php installation – but use it at your own risk. I’ll try to remember to keep it updated – but hopefully this will just get fixed upstream.

Here’s a link to the php 5.5 (5.5.9 to be precise) 64-bit patched pdo_odbc shared extension compiled on Ubuntu (Ubuntu 13.10 – but should work on most modern Ubuntu/Debian variants without any problems).

On non-Ubuntu/Debian platforms, you may get an error like the following:

"PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_odbc.so' - libodbc.so.1: cannot open shared object file: No such file or directory"

You’ll probably need to create some symlinks.

If you get an error about glibc – it’s because I’ve compiled this against glibc 2.14 initially. This is a problem for both Ubuntu 12.04 LTS and CentOS, so I’ll likely be recompiling this against glibc 2.12 in the very near future.

I have been somewhat vague with this post on purpose compared to my normal “tutorial” type posts I do, due the technical nature of the problems described here. You should not be following a tutorial or step-by-step procedure without fully understanding the steps you’re executing when it comes to hacking extensions/patches into your programming language runtime – unexpected results may occur, which is why I’ve posted my compiled extension AS-IS with a “Use at your own risk” disclaimer.

PHP 5.5+ and OPCode Caching

For those of us still using PHP:

With PHP 5.5, the time has come when users no longer have to seek out one of many OPcode caching alternatives. PHP 5.5 has OPcache built right in.

Oh, but your favorite framework/library/ORM doesn’t support OPcache because it no longer has userland caching functionality? Well, now we’re in quite a predicament; PHP upgraded, new OPcode caching via OPcache, and yet this setup feels like we’ve lost something. Don’t worry, you don’t have to run a memcache server and install a memcache extension just for userland caching – there’s APCu.

APCu is a fully functioning userland caching implementation that can be overly simplified with this equation:
The old APC extension – OPcache’s OPcode caching = APCu

If you have a lot of code that does detection of the old APC extension, you can even enable the compile flag --with-apc-bc to enable full APC compatibility mode.

Now you have no excuse – upgrade to PHP 5.5+.

codeLOL pt. 1 of many to come

Today’s subject – while it may be akin to beating a dead horse – is PHP.

With the recent increase in php bashing over the past twelve months, one might begin to ask: “Can it really be that bad?” The answer with a quick google search is – yes it can be pretty bad. I particularly like the last link (Jeff Atwood’s blog codinghorror) as it does a good job at stating the true problem and the reality of the situation: many legacy projects are still using php, and lots of development still happens in this language.

Quick aside: It just so happens, I work on some of those projects as part of my day job. I also use PHP in many of my personal projects and random tasks as it makes sense(which some would argue should never occur), as I’m relatively fast with PHP and it’s quick for me to prop up web apps or services to test against. I don’t really care which language I use most days, though sometimes things are so absurd that I just need to shake my head at the ridiculousness of it all.

Thus begins part one in a series that’s likely to have many occurrences – though I promise to make them much shorter as to only include chunks of code with very brief explanation in the post’s subject or URL as to why they’re codeLOL worthy. They also won’t all be php – you’re likely to see perl, ruby, objective-c, javascript, and many other languages (and possibly frameworks) featured as I run into personal codeLOL worthy moments.

And on to the codeLOL, this one I would normally title “to safely unserialize a native php-serialized object/variable”: