#42203 [Opn->Csd]: There are open database connections left

ID: 42203 Updated by: scottmac@php.net Reported By: zb at ispid dot com dot pl -Status: Open +Status: Closed Bug Type: SQLite related Operating System: Linux, NetBSD PHP Version: 4.4.7 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. I've fixed this in PHP 5.3. Previous Comments: ------------------------------------------------------------------------ [2007-08-03 19:28:23] zb at ispid dot com dot pl Description: ------------ I've encountered following problem when using PHP4-sqlite module (perhaps it's still to be found in PHP5?): One of my scripts doesn't make use out of database contents at all. But at the beginning there was a simple check for database file presence, just to let the user know, if there (from any reason) could be dbfile missing (the code in a window below). The problem was, that such sequence, after opening and then closing the sqlite database, by each call leaves persistent database connection (it can be easy checked using lsof), what - in several days of use - leads to the error message: (mod_fastcgi.c.2551) FastCGI-stderr: PHP Warning: sqlite_open() [<a ref='function.sqlite-open'>function.sqlite-open</a> malformed database schema - unable to open a temporary database file for storing temporary tables in /usr/local/www/index.php on line 25 ...and then one cannot connect to database anymore. There's a need to restart HTTP server then. Yes, the "$result = ..." line can be omitted (it is now, anyway...), because a successfull opening a database file is enough to check, whether the file is present, or not (although without SELECT it may be any other database file, with quite different tables). My problem was caused by the fact, that there was a "SELECT" query, but $result handle hasn't been processed any further. After commenting out the "$result = ..." line there are no more "persistent" open database connections. And the question: is it normal behaviour - or is it a bug in PHP-module? I've got a feeling, that after "sqlite_close($dbhandle)" there should be assumption, that the script will not use database anymore (until ev. next "sqlite_open"), so all ev. other handles related to database contents should be immediately removed. Reproduce code: --------------- if ($dbhandle = sqlite_open("/path/to/database/dbfile.db", 0666, $sqliteerror)) { $result = sqlite_unbuffered_query($dbhandle, 'select something from some_table'); sqlite_close($dbhandle); } else { die($sqliteerror); } Actual result: -------------- "lsof" output example: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME php 162 root 5u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 6u VREG 0,0 0 92290 / (/dev/wd0a) php 162 root 7u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 8u VREG 0,0 0 92318 / (/dev/wd0a) php 162 root 9u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 10u VREG 0,0 0 92319 / (/dev/wd0a) php 162 root 11u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 12u VREG 0,0 0 92317 / (/dev/wd0a) php 162 root 13u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 14u VREG 0,0 0 92321 / (/dev/wd0a) php 162 root 15u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 16u VREG 0,0 0 92331 / (/dev/wd0a) php 162 root 17u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 18u VREG 0,0 0 91348 / (/dev/wd0a) php 162 root 19u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 20u VREG 0,0 0 92328 / (/dev/wd0a) php 162 root 21u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 22u VREG 0,0 0 92332 / (/dev/wd0a) php 162 root 23u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 24u VREG 0,0 0 92322 / (/dev/wd0a) php 162 root 25u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 26u VREG 0,0 0 92334 / (/dev/wd0a) php 162 root 27u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 28u VREG 0,0 0 92333 / (/dev/wd0a) php 162 root 29u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 30u VREG 0,0 0 92198 / (/dev/wd0a) php 162 root 31u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 32u VREG 0,0 0 92337 / (/dev/wd0a) php 162 root 33u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 34u VREG 0,0 0 92336 / (/dev/wd0a) php 162 root 35u VREG 0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 36u VREG 0,0 0 92267 / (/dev/wd0a) php 162 root 37u VREG 0,0 613376 338233 /usr/local/db/databasefile.db ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=42203&edit=1