#20583 [Opn->Fbk]: Variable values inconsistent with assignment statements.
ID: 20583
Updated by: [EMAIL PROTECTED]
Reported By: jseverson at myersinternet dot com
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: RedHat 7.2
PHP Version: 4CVS-2002-11-22 (stable)
New Comment:
What is your php.ini setting for session.bug_compat_42 ?
Does turning that on/off change anything?
Previous Comments:
[2003-03-13 00:12:36] junkmail-trash at int0rnet dot net
I'm seeing this as well, on PHP 4.3.0 on Darwin -- it's
definately related to sessions.
My boss keeps asking why we aren't using Cold Fusion for
this project. I'm starting to have trouble coming up with
a good answer to keep using PHP..
[2003-02-26 17:12:56] jseverson at myersinternet dot com
On that same note, we have now rolled back all our servers to an older
version of php as this was bug was becoming impossible to work with.
[2003-02-26 17:12:10] jseverson at myersinternet dot com
Well, unfortunately I have bad news for you. Try using the empty() or
isset() functions on your new $_SESSION global variables. My guess is
they will always return true regardless of whether or not that variable
actually has a value. At least this was my experience when I did the
same thing you did, and went through replacing all my session
functions.
So for instance, in order to replace:
session_is_registered("variable")
you'd have to do:
!empty($_SESSION["variable"])
unfortunately, it always returns true!!
[2003-02-26 16:07:22] charlesk at netgaintechnology dot com
I forgot the session_start(); Still the same behaviour
Output : 5 2 3
Output: 5 2 2
[2003-02-09 16:38:22] phpbugs at brianmertens dot com
Maybe this is related to the bug #22117 , that
I reported yesterday?
http://bugs.php.net/bug.php?id=22117
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/20583
--
Edit this bug report at http://bugs.php.net/?id=20583&edit=1
#20583 [Opn->Fbk]: Variable values inconsistent with assignment statements.
ID: 20583 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: RedHat 7.2 PHP Version: 4CVS-2002-11-22 (stable) New Comment: So far every script in this report is buggy and can't possibly work. So fix your scripts first. Self-contained means that they can be run anywhere, regardless if there is oracle available or not. (ie. get rid of the oracle stuff in it) Short means it's less that 15 lines. Complete means it's all there, between tags. Previous Comments: [2003-01-27 16:38:52] [EMAIL PROTECTED] Oh, I should mention--- if you visit my demonstration, copy the link into your browser, do not click on it from here. If $HTTP_REFERER is actually set to something other than NULL the bug does not occur. Stephen. [2003-01-27 16:27:48] [EMAIL PROTECTED] Hi, I am sorry to hear the frustration! My script is self contained, and is of the minimum length to reproduce the problem. Just add some php tags! If you want to see similar code in action, see here: http://www.stephensykes.com/holwiz/ Note that the bug only occurs if you are creating the session for the first time - hence the session destroy at the top. If you session_register the variable $r before setting it, the bug does not occur. More specifically, it is only AFTER $r is registered that all variable assignments begin to take on the last value assigned. Regards Stephen. [2003-01-27 11:12:10] [EMAIL PROTECTED] I'm completely baffled here. Can you please explain how the two self-contained short scripts provided above are NOT samples of "_SHORT_, _COMPLETE_ and _SELF CONTAINED_ example scripts" ?? We've given you code to produce the bug in less than 20 lines. I don't know how many lines you are expecting us to reproduce the bug with? Thanks [2003-01-27 04:56:08] [EMAIL PROTECTED] Please provide a _SHORT_, _COMPLETE_ and _SELF CONTAINED_ example script. It's still some bug in your script, NOT in PHP.. [2003-01-26 12:12:51] [EMAIL PROTECTED] Ok, this is happening in 4.3.0. It does not happen in 4.2.2. Here is some self contained code: session_start(); session_destroy(); session_start(); $r = $HTTP_REFERER; session_register( "r" ); echo "r is "; var_dump($r); $z = 0; $x = 999; $y = 777; echo "x is " . $x . "\n"; echo "z is " . $z . "\n"; echo "y is " . $y . "\n"; I get $r is NULL, and 777 for all three of $x, $y and $z from this script. Something is badly wrong. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20583 -- Edit this bug report at http://bugs.php.net/?id=20583&edit=1
#20583 [Opn->Fbk]: Variable values inconsistent with assignment statements.
ID: 20583 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback -Bug Type: Variables related +Bug Type: Session related Operating System: RedHat 7.2 PHP Version: 4CVS-2002-11-22 (stable) New Comment: Please provide a _SHORT_, _COMPLETE_ and _SELF CONTAINED_ example script. It's still some bug in your script, NOT in PHP.. Previous Comments: [2003-01-26 12:12:51] [EMAIL PROTECTED] Ok, this is happening in 4.3.0. It does not happen in 4.2.2. Here is some self contained code: session_start(); session_destroy(); session_start(); $r = $HTTP_REFERER; session_register( "r" ); echo "r is "; var_dump($r); $z = 0; $x = 999; $y = 777; echo "x is " . $x . "\n"; echo "z is " . $z . "\n"; echo "y is " . $y . "\n"; I get $r is NULL, and 777 for all three of $x, $y and $z from this script. Something is badly wrong. [2003-01-23 14:00:26] [EMAIL PROTECTED] Haven't heard anything back on this bug in a while. Just wondering what the status was on this one, or if you've had any luck reproducing it with the code segment I provided. [2003-01-10 01:14:39] [EMAIL PROTECTED] I experienced the described problem with one of my scripts, too, since I upgraded the server to PHP 4.3.0. I use sessions, MySQL, and have cookies turned on in my browser. In my script I process post data and assign three values to session variables inside an if-statement. Changing the order in which the assignments are made (I moved the first statement after the other two) solved the problem, and all variables contain their correct values. I use Debian 3.0 (Woody), Apache 1.3.27 with statically linked PHP 4.3.0. PHP configuration: http://bigben171.wutallan.net/phpinfo.php [2002-12-30 10:58:02] [EMAIL PROTECTED] Well perhaps I initially reported the bug in the wrong category from the dropdown selection, since it seemed like it was a variables related problem. At this point, if I remove basically any of the lines from the code segment given above, the error goes away. So based on this, here are the three factors that I have been able to deduce are required to recreate the bug. 1) Turn off cookies 2) Use sessions 3) Use the OCI module. Basically, do everything I'm doing above in the code segment I sent you. If I could have simplified it any more, than I would have. However, the removal of any lines caused the problem to go away, which is what leads me to believe it's a combination of all three of the things I just listed. >From the sample output I gave you, you can see that it's interpretting a simple string assignment statement to the $sql variable as some sort of object/resource. This is why I reported the bug as a variables related issue, but maybe it isn't. Maybe it's all related to the OCI module and PHP sessions. Thank you. [2002-12-19 19:30:54] [EMAIL PROTECTED] 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: 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20583 -- Edit this bug report at http://bugs.php.net/?id=20583&edit=1
#20583 [Opn->Fbk]: Variable values inconsistent with assignment statements.
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:
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.
__
";
print "Another = $another";
print "Obviously Messed Up = $obviously_messed_up";
?>
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: server => $servererrno =>
$errnoerrstr => $errstrwhoknows => $whoknows";
if(empty($server)) {
print "server is empty, so changing values";
$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: server => $servererrno =>
$errnoerrstr => $errstrwhoknows => $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
#20583 [Opn->Fbk]: Variable values inconsistent with assignment statements.
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:
Please provide us a complete, self-contained and short script which can
be used to reproduce this.
(you're most likely doing something wrong..)
Previous Comments:
[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: server => $servererrno =>
$errnoerrstr => $errstrwhoknows => $whoknows";
if(empty($server)) {
print "server is empty, so changing values";
$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: server => $servererrno =>
$errnoerrstr => $errstrwhoknows => $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
#20583 [Opn->Fbk]: Variable values inconsistent with assignment statements.
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:
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
Previous Comments:
[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: server => $servererrno =>
$errnoerrstr => $errstrwhoknows => $whoknows";
if(empty($server)) {
print "server is empty, so changing values";
$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: server => $servererrno =>
$errnoerrstr => $errstrwhoknows => $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
