Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PECL better.

You need to build a debug build of PHP to obtain a better backtrace.

Here is another bt from core. The only difference is this time its complied with clisapi.

#0  0x014b7a2c in ?? ()
#1  0x00b205d7 in exit () from /lib/tls/libc.so.6
#2  0x081fde7d in main (argc=3, argv=0xbffcb6c4) at /home/jhannus/local/src/php-5.0.4/sapi/cli/php_cli.c:1062

Note. The above bt was also built with --enable-debug.

Can you build against uodbc instead of DB2 on that box and see if that has the same behaviour, just for the sake of comparison?

Justin: you asked if PDO_ODBC supports IBM-DB2v7.2. Given that IBM does not support DB2 V7.2 anymore (it was out of service as of Sept 2004 -- http://www-1.ibm.com/support/docview.wss?rs=71&uid=swg21168270) it might be better to focus on something newer, like DB2 V8.2.

By the way, by "uodbc", I think Wez means unixODBC. This would be an interesting comparison.

Another interesting comparison would be seeing if compiling Unified ODBC against DB2 (--with-ibm-db2) results in the same segfault.

Wez,
So I don't get segfaults when pdo_odbc is compiled against uodbc-2.2.9.  As soon as i disable that and enable db2 pdo_odbc i get the same segfault.  I can infact use the driver, make a connection, but all query()'s throw a PDOException with the message:

'SQLSTATE[22003]: Numeric value out of range: -99999 [IBM][CLI Driver] CLI0111E  Numeric value out of range. SQLSTATE=22003 (SQLFetchScroll[-99999] at /home/jhannus/local/src/PDO_ODBC-0.2/odbc_stmt.c:300)' 

I have other pdo drivers installed fine too.
--

dbs,
Yeah, i know. But upgrading to 8.2 isn't something we're interested in right now although its a posibility. We're moving some existing products to PHPv5 and new hardware, and possibly new database software--in phases. So i could try ibm-db2 extension but I'm only interested in db abstraction like PDO. Currently we're using php's odbc with db2. My fallback is to have all regular db extensions installed and just use PEAR's DB. This way i can, in theory :), swap out one db implementation for another at anytime. Which may just happen to me in a few months ;)

Heres some more info with different test:

code:
<?php
try {
    $dbo = new PDO($schema, $user, $pass, array (
        PDO_ATTR_PERSISTENT => true)
     );
     $dbo->setAttribute(PDO_ATTR_ERRMODE, PDO_ERRMODE_EXCEPTION);
     echo "PDO object created.\n";
} catch (PDOException $e) {
    die("Error connectiong: ".$e->getMessage()."\n");
}

$sql = 'select p.PROD_ID from GR.PRODUCT as p where p.PROD_ID = 2520 for read only';

try {
    foreach ($dbo->query($sql) as $row) {
        print_r($row);
    }
} catch (PDOException $e) {
    die("Error in query: ".$e->getMessage()."\n");
}

?>

output:
PDO object created.
Array
(
    [PROD_ID] => 2520
    [0] => 2520
)
/home/jhannus/local/src/php-5.0.4/ext/pdo/pdo_stmt.c(1942) :  Freeing 0x08B37ABC (4 bytes), script=/home/jhannus/pdoTest.php
/home/jhannus/local/src/php-5.0.4/Zend/zend_API.c(990) :  Freeing 0x08B37A64 (35 bytes), script=/home/jhannus/pdoTest.php
/home/jhannus/local/src/php-5.0.4/Zend/zend_hash.c(383) : Actual location (location was relayed)
/home/jhannus/local/src/php-5.0.4/Zend/zend_hash.c(242) :  Freeing 0x08B37A04 (43 bytes), script=/home/jhannus/pdoTest.php
/home/jhannus/local/src/php-5.0.4/ext/pdo/pdo_stmt.c(735) :  Freeing 0x08B379B4 (32 bytes), script=/home/jhannus/pdoTest.php
/home/jhannus/local/src/php-5.0.4/Zend/zend_hash.c(169) : Actual location (location was relayed)
Last leak repeated 1 time
/home/jhannus/local/src/php-5.0.4/ext/pdo/pdo_stmt.c(829) :  Freeing 0x08B3BCFC (16 bytes), script=/home/jhannus/pdoTest.php
/home/jhannus/local/src/php-5.0.4/ext/pdo/pdo_stmt.c(470) :  Freeing 0x08B3BBCC (5 bytes), script=/home/jhannus/pdoTest.php
/home/jhannus/local/src/php-5.0.4/ext/pdo/pdo_stmt.c(2007) :  Freeing 0x08B2A794 (16 bytes), script=/home/jhannus/pdoTest.php
=== Total 8 memory leaks detected ===
Segmentation fault

bt:
#0  0x014c4a2c in ?? ()
#1  0x00b205d7 in exit () from /lib/tls/libc.so.6
#2  0x081fde7d in main (argc=3, argv=0xbfe98ad4) at /home/jhannus/local/src/php-5.0.4/sapi/cli/php_cli.c:1062

From the above output one might think that its not pdo_odbc that causes the segfault but php only segfaults whith pdo_odbc enabled (with db2). Another interesting thing to note is that there looks like an extra key => value in the result array.

Even more interesting...

As i said before, the segfault only happens when pdo_odbc.so is enabled and compiled against db2(v7.2). To add another variable to the mix, the segfault only happens when I have the $DB2* env vars defined after source'ing the db2profile script, which is a must. Once the db2 related variables are unset the segfault goes away.

$ env
DB2INSTANCE=db2inst1
DB2DIR=/opt/db2-base/IBMdb2/V7.1
...more stuff...
...and also...
LD_LIBRARY_PATH=:/opt/db2-user/db2/db2inst1/sqllib/lib
LIBPATH=:/opt/db2-user/db2/db2inst1/sqllib/lib
...

Sounds like this bug could be a db2 thing? But... PHP should always exit gracefully. I've exhausted all my debugging, if you have any other ideas or need more info please let me know. I hope you found this useful.

-justin

My gut feeling is that the db2 libraries are segfaulting in an atexit() handler they added; PHP dlunloads the .so and the registered atexit() functions now point off into space.

If you build pdo and pdo_odbc statically into PHP, you might have better luck.

http://netevil.org/node.php?uuid=420dc046-e4b8-6943-7672-20dc046b0eda has a guide for building PDO statically under OSX; it should be accurate for linux too; just substitute PDO_ODBC for PDO_SQLITE.

"Another interesting thing to note is that there looks like an extra key => value in the result array."

Actually, this is the default fetch type in PDO (PDO_FETCH_BOTH) -- you get both numerically indexed (by column number) and an associative (by column name) array.

BTW, grabbed PDO 0.3 and PDO_ODBC 0.2 through pear installer and they work fine with DB2 8.2.

Wez,
Your abosultely right. Compiling statically gets no segfault.  


> Actually, this is the default fetch type in PDO (PDO_FETCH_BOTH)

Silly me, I probably should have RTFM. Strange that PDO_FETCH_BOTH is the default though. 

>BTW, grabbed PDO 0.3 and PDO_ODBC 0.2 through pear installer and they work fine with DB2 8.2

Since you bring it up, can db2 client 8.2 connect to db2 7.2 server?

Umm, not trying to make this into a DB2 support line, but the answer to the DB2 8.2 client -> 7.2 server connection question is "yes, with restrictions": see http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/start/r0009731.htm

Or for a URL that doesn't wrap: http://tinyurl.com/8ub2h

Please try your original build configuration (shared extensions) against PHP HEAD.

If that works fine you've found a bug in the PHP shutdown sequence in the 5.0 branch, and should open a regular PHP bug for the issue.

Otherwise, this is a problem with atexit() as I suggest in an earlier comment.

In either case, this doesn't appear to be a PDO specific error, so I'm marking this as a bogus report.

If you see something totally weird with HEAD and it seems PDO related, please reopen this report.

> Please try your original build configuration (shared extensions) against
PHP HEAD.

Attempting to build a shared build of pdo_odbc fails for me with snapshot php5-200506141430:

./configure --with-pdo-odbc=ibm-db2,/opt/db2-base/IBMdb2/V7.1 --with-php-config=/home/jhannus/local/php/bin/php-config
...
checking for ODBC v3 support for PDO... yes, shared
checking for PDO includes... checking for PDO includes... /home/jhannus/local/php/include/php/ext
checking for selected PDO ODBC flavour... ibm-db2
          libs       /opt/db2-base/IBMdb2/V7.1/lib,
          headers    /opt/db2-base/IBMdb2/V7.1/include
checking for SQLBindCol in -ldb2... no
configure: error: Your ODBC library does not exist or there was an error. Check config.log for more information

But when building statically it compiles fine.

-Justin