ID: 20583
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Variables related
Operating System: RedHat 7.2
PHP Version: 4CVS-2002-11-22 (stable)
New Comment:
you're focussing on the wrong issue. It should be *self-contained*. Can
you still reproduce the issue, when you strip the ora_* stuff and
without sessions? If not, add sessions back in, then the ora_*.
>From what you're reporting:
<?php
$one='one';
$two='two';
print "$one $two";
?>
should result in 'one one'.
If this isn't the case, then it's not a variable issue, but specific to
some module. Unless we find out what module causes the behavior,
there's not much we can do.
Previous Comments:
------------------------------------------------------------------------
[2002-12-19 15:25:15] [EMAIL PROTECTED]
Ok, I've been able to narrow this bug down to a much simpler PHP
script. We have also confirmed that it is definitely a problem with the
newer version of PHP since we are running an identical script on
production, with an older version of PHP, and it is error free.
The following script should allow you to recreate the problem. You
should disable cookies on the browser in order to have the error
recreated each subsequent refresh. Otherwise, the error will only
happen the first time you view the page, and will be gone on
refreshes.
______________________________________________________
<?
session_start();
$db_sid = "SID_VALUE";
$oralogin = "scott";
$orapass = "tiger";
$conn_ora = OCIPLogon($oralogin, $orapass, $db_sid);
if (empty($_GET["view_all"])) {
$_GET["view_all"] = $_SESSION["view_all"];
}
$view_all = $_GET["view_all"];
session_register("view_all");
$sql = "select SOME_FIELDS_FROM_DATABASE ";
if ($mgt_user_row["SUPER_USER_FLAG"] == "Y" && $_GET["view_all"] ==
"Y") {
$sql .= "from SOME_TABLE_NAMES ";
} else {
$sql .= "from SOME_TABLE_NAMES ";
}
$another = "hello world";
$obviously_messed_up = "php";
$stmt = OCIParse($conn_ora, $sql);
print "SQL = $sql<br>";
print "Another = $another<br>";
print "Obviously Messed Up = $obviously_messed_up<br>";
?>
____________________________________________________
Output of Above Code:
SQL = Resource id #3
Another = Resource id #3
Obviously Messed Up = Resource id #3
------------------------------------------------------------------------
[2002-12-11 01:03:31] [EMAIL PROTECTED]
Please provide us a complete, self-contained and short script which can
be used to reproduce this.
(you're most likely doing something wrong..)
------------------------------------------------------------------------
[2002-12-10 19:12:37] [EMAIL PROTECTED]
We have upgraded our PHP to the version given below, and are still
experiencing the same problems.
Thanks
------------------------------------------------------------------------
[2002-12-07 15:41:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
------------------------------------------------------------------------
[2002-11-22 12:58:04] [EMAIL PROTECTED]
I haven't been able to recreate this problem at all in a controlled
environment, but I can recreate it consistently where we originally
discovered it.
Here is the snidbit of the function causing the erroneous output:
_______________________________________________________
function do_mail_command($cmd,$server="morpheus.myersinternet.com") {
print "values prior to setting are:<p> server => $server<br>errno =>
$errno<br>errstr => $errstr<br>whoknows => $whoknows<br>";
if(empty($server)) {
print "<br>server is empty, so changing values<p>";
$server = "this is the first one";
$errno = "here is the second one";
$errstr = "but they will all be this";
$random_variable = "does this work";
print "values after setting:<p> server => $server<br>errno =>
$errno<br>errstr => $errstr<br>whoknows => $whoknows";
}
$fp = fsockopen($server, 5154, $errno, $errstr, 10);
_________________________________________________________
Here is the output of that exact piece of code:
values prior to setting are:
server => morpheus.myersinternet.com
errno => morpheus.myersinternet.com
errstr => morpheus.myersinternet.com
whoknows => morpheus.myersinternet.com
server is empty, so changing values
values after setting:
server => does this work
errno => does this work
errstr => does this work
whoknows => does this work
____________________________________________________
There are three main problems I see occurring here.
1. The first print statement prints out a bunch of "random" variables,
$server being the only that has previously been given a value. However,
as the print statement shows, they ALL have values.
2. The empty($server) check returns true even though its obviously
clear that $server is NOT empty.
3. After performing variuos assignment statements within the if block,
and printing out the variable values, it's clear that ALL the variables
receive the value of the LAST assignment statement made.
We found this bug because when calling fsockopen, the $errno and
$errstr variables had values even though they were never assigned any
values and it was causing the function to fail when trying to open the
socket. This function was working fine prior to our upgrade to the
latest version.
Our configure line is:
LoadModule php4_module modules/libphp4.so
We are also heavily using session variables in case that helps to
recreate the bug.
Thanks
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=20583&edit=1
