Trying to write an ODBC PDO driver for CakePHP. Seems like I get closer and closer however whenever a PDO function is called that it doesn't like the connection just gets reset immediately and I'm not able to get any error information whatsoever. I'm thinking this could be a possible config setting but I can't find anything. I dunno if this will help but here is the particular snippet I'm working with:

public function fetchResult() {
    if ($row = $this->_result->fetch()) { // ### HERE IS WHERE IT RESETS ###
        $resultRow = array();
        foreach ($this->map as $col => $meta) {
            list($table, $column, $type) = $meta;
            if ($table === 0 && $column === self::ROW_COUNTER) {
            $resultRow[$table][$column] = $row[$col];
            if ($type === 'boolean' && !is_null($row[$col])) {
                $resultRow[$table][$column] = $this->boolean($resultRow[$table][$column]);
        return $resultRow;
    return false;

The only difference between this method and the original CakePHP fetchResult function is that I'm not passing in the PDO::FETCH_NUM argument but either way still doesn't work!


There are deeper issues.

I'm certain this is a bug: https://bugs.php.net/bug.php?id=64483


I'm experiencing a similar issue. Try checking your error logs for:

[notice] child pid 16759 exit signal Segmentation fault (11)

I'm not trying to use PDO, but using ODBC I get crashes too. It only happens when an SQL statement returns null. People have suggested using COALESCE(field, '') to return empty strings, but that is a ridiculous workaround. Also there is a bug in PHP that relates to this as well, looks like 5.3.11 is when the null bug was corrected. My issue now seems to be a mismatch of 64-bit & 32-bit softwares. Another thing worth noting is that the bugs reported were 64-bit only.

LAMP using ODBC to DB2

  • OMG! "AH00052: child pid 5808 exit signal Segmentation fault (11)". Also getting "zend_mm_heap corrupted" – Shawn Welch Mar 21 '13 at 20:12
  • OK so for starters check the output of phpinfo(), specifically PHP version. Also compare odbc.ini (in /etc/unixODBC?) to phpinfo() (ctrl+f for odbc) and make sure you don't have a 32/64-bit mismatch, and I'll assume that something somewhere is 64-bit (straight 32-bit seems to work no problem). Also read bug 54007's comments 2nd from the end: "It seems that when field is null the ODBC driver return the pointer of somewhere in the memory..." and all I could think was, huh? Lastly run a query that is guaranteed to not return any null fields and see if that works. – MaKR Mar 21 '13 at 20:34
  • Everything on my end is 32 bit for sure. – Shawn Welch Mar 22 '13 at 4:24
  • Weird.... Well a few questions then, what is the type of database you're connecting to? And what about queries that specifically do and don't return null fields? – MaKR Mar 22 '13 at 13:53
  • I'm connecting to a MSSQL Server 2005 via ODBC/FreeTDS. I'm 100% certain that the query I'm running works. I've tried it independently in Access. I don't think it has to do with nulls. Check out the link to the php bugs that I posted in the above answer. – Shawn Welch Mar 22 '13 at 14:34

In my case the problem was cause my db includes accented non US text. Change my selects to "SELECT field Collate SQL_Latin1_General_CP1253_CI_AI FROM database WHERE clauses" and works!

  • Oh, nice, thank you! I don't know if I will ever deal with this problem again but good to know. If you are sure you have solved the problem then I will accept this as the answer. – Shawn Welch Feb 25 '17 at 16:27

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.