Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip

I tried downloading the last snapshot for win32 but it now completely crashes my applcation. The XML DOM extension seems to be the issue

# Suspected Code
$doc = new DOMDocument;
$doc->Load(CONFIG_PATH);
if (!$doc->validate()) {
    throw new Exception("Mapping file is not valid");
}

Also I still have the DB2/ODBC problem :

# Problematic code example
try {
  $dbh = new PDO('odbc:TEST', 'user', 'password');
} catch (Exception $e) {
  echo "Failed: " . $e->getMessage();
}
$stmt = $dbh->query("SELECT * FROM Table1");
$stmt->setFetchMode(PDO::FETCH_ASSOC);
$rs = $stmt->fetchAll();
echo count($rs) . " : ";

when correct query should be SELECT * FROM SCHEMA1.Table1
crashes Apache before $stmt->setFetchMode(PDO::FETCH_ASSOC);

Assigned to the maintainer.

Can you reproduce this with mssql or access?

Confirmed the problem here with php5-win32-200512111930.zip from snaps.php.net, as well as php-5.1.1 Windows binary from php.net, running PHP CLI (taking Apache out of the equation).

This is with DB2 V8 FixPak 10, using the DB2 sample database cataloged as a SYSTEM ODBC data source.

Windows XP SP1 with all current (non SP2) fixes.

My slight variation: SELECT * FROM EMPLOYEE works as expected, but SELECT * FROM FOO.EMPLOYEE (non-existent schema) causes Windows to pop up one of those handy little "CLI has encountered a problem and needs to close. Would you like to send this error report to microsoft?" dialogs.

I would expect an error message like the following:

SQL0204N  "FOO.EMPLOYEE" is an undefined name.  SQLSTATE=42704

I couldn't reproduce the issue, but by working with Dan, did manage to get a couple of backtraces that highlighted some code that might cause something like this to happen.

Please try the next snapshot dated after this message to see if that nailed it.

Hmm. Still getting a crash and the same backtraces with snapshot built On: Dec 14, 2005 11:30 GMT (SQLBindParameter with pdo_odbc.connection_pooling=off, SQLDriverConnectW with pdo_odbc.connection_pooling=strict or relaxed).

mrethers, what version of odbc32.dll is installed on your system?

Dan's system(crashes):  3.520.9042.0
Wez's system(no crash): 3.525.1117.0

Additional test:

On a system with Windows XP SP2, DB2 Run-Time Client Lite Version 8 FixPak 10, odbc32.dll version 3.525.1117.0, connecting to a DB2 database, I still get a crash. So much for the odbc32.dll theory... Here's the backtrace using php-5.1-win32-200512180730:

0:000> kv
ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f8c8 74327f94 00000000 10008ec0 00abce70 ODBC32!MpHeapAlloc+0x435
0012f8e8 7434350b 003b1db0 00000001 000003ee ODBC32!SQLDisconnect+0x147
*** WARNING: Unable to verify checksum for C:\Programs\php5.1-snap\ext\php_pdo_odbc.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Programs\php5.1-snap\ext\php_pdo_odbc.dll
 -
0012f904 00391c75 00000003 74350000 1009a470 ODBC32!SQLFreeHandle+0x1f3
00000000 00000000 00000000 00000000 00000000 php_pdo_odbc+0x1c75
0:000>

This is using a modified version of mrethers' test case. I thought it was bad form to access $stmt->fetchAll() when $stmt was not a valid object, so simplified the test case to this:

<?php
# Problematic code example
try {
  $dbh = new PDO('odbc:SAM', 'test', 'test');
} catch (Exception $e) {
  echo "Failed: " . $e->getMessage();
}
$stmt = $dbh->query("SELECT * FROM foo.Employee");
?>

(where foo.Employee is a table that does not exist in the target database... same test works fine if I point to a table that does exist in the database).

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I still have the same problem with PHP 5.2.3, and not only with PDO but also with the ODBC extension (odbc_connect(), etc).

I have an older update of Win XP: SP1, and my odbc32.dll version is 3.520.90.42.0.

Apache's logs say a child process exited with status 3221225477 when this happens.

When Apache crashes and I don't stop my browser from loading, once Apache picks up again it continues doing what it was doing and the rest of my PHP script runs as it should.

This code:

<?php
$db = odbc_pconnect( 'rentmasterdb', 'George Washington', '' );
print_r( odbc_fetch_array( odbc_tables( $db ) ) );
?>

Crashes Apache at odbc_pconnect(), then yields the first returned row:

Array
(
    [TABLE_CAT] => C:\PROGRAM FILES\RENTMASTER INC\RENTMASTER\DATA
    [TABLE_SCHEM] => 
    [TABLE_NAME] => addresses
    [TABLE_TYPE] => TABLE
    [REMARKS] => 
)

So it connects OK after getting by the Microsoft error reporting dialogs and restarting the child process. I thought using a persistent connection might only crash it on the first run and then not crash when it picks up the connection later, but I'm using the PHP CGI binary so I guess that's why it didn't work.