php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #42203 There are open database connections left
Submitted: 2007-08-03 19:28 UTC Modified: 2008-03-08 04:20 UTC
From: zb at ispid dot com dot pl Assigned:
Status: Closed Package: SQLite related
PHP Version: 4.4.7 OS: Linux, NetBSD
Private report: No CVE-ID: None
 [2007-08-03 19:28 UTC] 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


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-03-08 04:20 UTC] scottmac@php.net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 11:01:29 2024 UTC