Bug #229

getXxx methods return null result when used with $params array

Details

Submitted	2003-11-12 18:02 UTC
From	patrick dot lambert at noggin dot com
Assigned	danielc
Status	Closed
Package	DB
PHP Version	4.3.3
OS	Solaris
Roadmaps	(Not assigned)

Comments

[2003-11-12 18:02 UTC] patrick dot lambert at noggin dot com

Description:
------------
When a $params array is included in a getXxx call (as the
documentation indicates is valid and will cause the statement to go
through prepare/execute), a null result is returned.

I tested this under PHP 4.3.4 and 4.3.3 with DB 1.5.0RC2 against
and Oracle 8.1.7 database on Solaris.

Reproduce code:
---------------
supposing that you have a DB on the backend with appropriate data, this...
$param_array = array(147, 1);
$sql = "select foo from bar where baz = ? and xyzzy = ?";
$row = $db->getRow($sql, $param_array);

should produce the same results as this...

$sql = "select foo from bar where baz = 147 and xyzzy = 1";
$row = $db->getRow($sql);

or this...

$param_array = array(147, 1);
$sql = "select foo from bar where baz = ? and xyzzy = ?";
$sth = $db->prepare($sql);
$result = $db->execute($sth, $param_array);
$row = $result->fetchRow();

Expected result:
----------------
All three phrasings should produce the same value for $row.

Actual result:
--------------
getRow with params returns a null result while the other
two phrasings return valid data.

[2003-11-21 18:37 UTC] cwhatley at pobox dot com

The problem lies with the freePrepared() method of
oci8.php's object. The call to ocifreestatement() within
that method trashes the result of the fetch. More
investigation coming.

[2003-11-23 14:12 UTC] cwhatley at pobox dot com

It looks like there's no memory leak when you take out
the offending ocifreestatement() call in oci8's
freePrepared() method. As I surmised, the resources are
being freed up as part of normal garbage collection. I
ran with a loop around the fetch with bind vars and
after 450,000 fetches, the memory usage was stable (see
below).

This was the same fetch over and over again. One thing I
can't effectively test in isolation is how a wide
variety of fetches affect memory use. This may have
different results.

PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT
RSHRD RSIZE VSIZE
23909 php 1.3% 0:01.83 1 13 50 2.72M
7.34M 6.82M 41.7M
23909 php 5.5% 0:04.28 1 13 51 2.75M
7.34M 6.83M 41.7M
23909 php 4.1% 0:06.97 1 13 51 2.75M
7.34M 6.83M 41.7M
23909 php 4.1% 0:08.80 1 13 52 2.75M
7.34M 6.84M 41.9M
23909 php 1.4% 0:16.18 1 13 52 2.75M
7.34M 6.84M 41.9M
23909 php 0.7% 0:19.32 1 13 52 2.76M
7.34M 6.84M 41.9M
23909 php 2.2% 2:39.00 1 13 52 2.83M
7.34M 6.91M 41.9M
23909 php 5.1% 2:58.01 1 13 52 2.84M
7.34M 6.92M 41.9M
23909 php 2.7% 4:28.91 1 13 52 2.88M
7.34M 6.96M 41.9M
23909 php 4.2% 6:27.26 1 13 52 2.88M
7.34M 6.96M 41.9M
23909 php 4.8% 7:26.90 1 13 52 2.85M
7.34M 6.96M 41.9M
23909 php 4.1% 7:56.90 1 13 52 2.85M
7.34M 6.96M 41.9M
23909 php 4.1% 8:26.10 1 13 52 2.85M
7.12M 6.96M 41.9M
23909 php 2.0% 9:50.96 1 13 52 2.85M
7.12M 6.96M 41.9M
23909 php 8.6% 11:20.55 1 13 52 2.85M
7.12M 6.96M 41.9M
23909 php 6.0% 12:50.39 1 13 52 2.85M
7.12M 6.96M 41.9M
23909 php 7.0% 13:51.43 1 13 52 2.85M
7.12M 6.96M 41.9M
450,000 fetches

The change on 4.3.4's oci8.php:

*** oci8.php Sat Nov 22 22:18:43 2003
--- /usr/local/lib/php/DB/oci8.php Tue Nov 11 23:
40:15 2003
***************
*** 246,252 ****
if (!is_resource($stmt)) {
return false;
}
! //ocifreestatement($stmt);
unset($this->prepare_tokens[(int)$stmt]);
unset($this->prepare_types[(int)$stmt]);
unset($this->manip_query[(int)$stmt]);
--- 246,252 ----
if (!is_resource($stmt)) {
return false;
}
! ocifreestatement($stmt);
unset($this->prepare_tokens[(int)$stmt]);
unset($this->prepare_types[(int)$stmt]);
unset($this->manip_query[(int)$stmt]);
***************

[2003-12-05 19:45 UTC] patrick dot lambert at noggin dot com

Can someone with cvs privs commit this patch?