#33910 [NEW]: Fix of bug #30578 not necessarily correct

From: jrweir at gmail dot com Operating system: all PHP version: 5.1.0b3 PHP Bug Type: Output Control Bug description: Fix of bug #30578 not necessarily correct Description: ------------ http://bugs.php.net/bug.php?id=30578 I don't think the way this bug was solved was correct. While I agree the example code posted above should work as expected, a side effect of fixing this caused all destructors to run before registered ob handlers. Destructors used to run after an ob handler, which was very useful for analyzing script output and setting flags for objects to clean themselves up appropriately. Consider the following (which is now not possible in 5.1): <?php ob_start('outputHandler'); function outputHandler($buffer){ // find out if there was a fatal error. If none, allow sql connections to commit on destruct if (!preg_match('/((Fatal|Parse) error: .+ in .+ on line \d+)/', strip_tags($buffer), $matches)) SQL::setAllowCommit(true); return $buffer; } class SQL { private $connection; private static $allowCommit=false; public function __construct(){ } public function __destruct(){ if ($this->connection && self::getAllowCommit()) { $this->connection->commit(); echo ' commit happened '; } else echo ' no commit happened '; } public static function getAllowCommit() { return self::$allowCommit; } public static function setAllowCommit($val) { self::$allowCommit = $val; } public function connectToDatabase($host, $user, $pass, $db){ $this->connection = new mysqli($host, $user, $pass, $db) or die('no connection'); $this->connection->autocommit(false); } public function query($sql) { return $this->connection->query($sql); } } $dbOne = new SQL(); $dbOne->connectToDatabase('localhost', 'user', 'pass', 'db1'); $result = $dbOne->query("update tab set col = 'val'"); $dbTwo = new SQL(); $dbTwo->connectToDatabase('localhost', 'user', 'pass', 'db2'); $result = $dbTwo->query("update tab set col = 'val'"); ?> This simple example would be able to tell if a fatal error happened in the script and only allow the db connections to commit their transactions if there was no error. There is no way to do this now in php 5.1 (I realize I could achieve a similar affect by storing all the open connections and calling some other method from the ob handler, but then the destructors have no real purpose if not for cleanup based on the exit status of a script). The original example of this "bug" is really just pointing out contradicting functionality. I would assume that output buffering would not be allowed in destructors (as it is not allowed in output buffering handlers). If by waiting for all variables to go out of scope before the buffer flush, then there is even a bigger contradiction. -- Edit bug report at http://bugs.php.net/?id=33910&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33910&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33910&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33910&r=trysnapshot51 Fixed in CVS: http://bugs.php.net/fix.php?id=33910&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=33910&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33910&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33910&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33910&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33910&r=support Expected behavior: http://bugs.php.net/fix.php?id=33910&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33910&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33910&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=33910&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33910&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=33910&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33910&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33910&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33910&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33910&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33910&r=mysqlcfg