Description:
------------
If an error happens while executing PDO::query() causing FALSE to be returned, or a PDOException to be thrown, the result is that a reference is held to the PDO object and the database connection is not released until the script is terminated.

This creates a memory leak in PHP, and an exhaustion of resources on the Database Server being used, which could become a security issue. 

This leak will not be noticible when running PHP as a web page, but is painfully a problem when creating long-term CLI scripts that are always running, connecting to a database, performing operations, closing, sleeping, and repeating.  Eventually all allowable connections to your database server will be used up creating a denial of service problem, leading to other possible security issues.

The sample code is short, but when combined with a monitoring of the network connections to your database server, you will see that all connections remain in ESTABLISHED state (via netstat -an) even though the $dbh value is set to NULL on each iteration.

Because of the error in the PDO::query() call, setting $dbh to NULL does not have the effect of releasing the connection because there is a held reference to the object--namely the PDOStatement that is created internally within PDO::query() but never returned to the calling program due to the error.

Note that persistent connection pooling is not the problem here as the test script specifically instructs the code NOT to use persistent connections in order to demonstrate the memory leak.  To ensure this further, all "persistent" settings in php.ini were set to completely disable connection persistence.

The bug is patched easily with the attached patch for the ext/pdo/pdo_dbh.c file (1 line of code is moved).

The reason for moving the line in question is because during the error, the created "stmt" object CANNOT be returned to the calling program.  Thus, the destructor of the stmt cannot go off, and the reference count to the "dbh" object will never decrease to allow its destructor to do cleanup.

Furthermore, since the stmt object created prior to line 1125 of pdo_dbh.c has a reference to the dbh added to it.  A matching UNreference must be done if the object is not going to be returned.  Without the patch, the reference is only removed following the PDO_HANDLE_DBH_ERR() macro, when it should be de-referenced after EITHER PDO_HANDLE_DBH_ERR() OR PDO_HANDLE_STMT_ERR().

Since the "stmt" object is not returned during an error condition, the zval_dtor() call is required.  This will in turn allow the "stmt" to call php_pdo_dbh_delref() thus letting the dbh object die when it is set to null.

Test script:
---------------
$options = array(
   PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
   PDO::ATTR_PERSISTENT => false,
);
for($i = 0; $i < 10; $i++) {
   $dbh = new PDO("mysql:dbname=$dbname;host=$host", $user, $password, $options);
   $sql = "SELECT 1 FROM table_that_does_not_exist LIMIT 1";
   try {
      $rs = $dbh->query($sql, PDO::FETCH_ASSOC);
      $rs->closeCursor();
      print "Table exists\n";
   } catch (Exception $e) {
      print " MSG: ".$e->getMessage()."\n";
   }
   sleep(3);
   unset($rs);
   $dbh = null;
}

while (1) {
   print "sleep\n";
   sleep(10);
}


Expected result:
----------------
MSG: SQLSTATE[42S02]: Base table or view not found: 1146 Table '<DBNAME>.table_that_does_not_exist' doesn't exist
...
<repeat above 10 times>
...
sleep
sleep
sleep
...

The above output will appear, but you must ALSO check "netstat -an|grep :3306" at the same time the script is running..

What is expected is that a SINGLE "ESTABLISHED" connection is present, along with a varying number of TIME_WAIT state connections while the loop goes about opening and closing the PDO connection on each iteration.

Actual result:
--------------
What you see in "netstat -an|grep :3306" is multiple connections in ESTABLISHED state, that remain that way until the script is terminated with CTRL-C