ID: 20728
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: Linux 2.4.x
PHP Version: 4.2.3
New Comment:
I get this normal output:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
int(1)
}
No bug here. (using PHP 4.3.0-dev)
Previous Comments:
------------------------------------------------------------------------
[2002-12-01 16:07:16] [EMAIL PROTECTED]
Hello,
I don;t think it is quote as easy as saying "Don't use global with the
autoglobal arrays.". Please read my original bug post. I went out of
my way to be very detailed so that I don't waste your time - this does
nobody any good though if you don't take the time to read it. More
specifically, this is the part I am referring to:
<ORIGNAL BUG POST>
So now you are asking that is interesting, but why would you ever want
to "global" an autoglobal. Good question! There would be no purpose
in doing this since $_SESSION is always in scope. Well, this bug
presented itself to me in an application where there was a reference to
a portion of $_SESSION. Since the application is over 5000 lines of
code, we will view a highly condensed test version of this:
<?php
session_start();
echo 'Before session modifications:<br><pre>';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
$foobar = $_SESSION['foobar'];
global $foobar;
$foobar = 3;
echo '</pre>After session modifications:<br><pre>';
var_dump($_SESSION);
?>
</ORIGNAL BUG POST>
So the bug presents itself when you "global" a reference to an array
element of an autoglobal as well. Perhaps, I should have used this as
the original code example. Please take the time to read the full bug
post.
Thank You,
Mike
------------------------------------------------------------------------
[2002-11-29 20:58:08] [EMAIL PROTECTED]
Don't use global with the autoglobal arrays.
------------------------------------------------------------------------
[2002-11-29 17:59:17] [EMAIL PROTECTED]
Hello,
I have compiled the latest snap shot at
http://snaps.php.net/php4-latest.tar.gz. The only change I had to make
for the PHP compiling process was to update my version of curl since
the snapshot requires curl-7.10.2 (the latest stable release). It
compiled fine, I restarted the web server, and the same problem still
occurs with the same code from my original bug post.
Please let me know if you need any additional information.
Mike
------------------------------------------------------------------------
[2002-11-29 15:23:07] [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-29 13:53:57] [EMAIL PROTECTED]
First, please ignore my comment on bug #17959, I have further
investigated this
issue to narrow down exactly what is causing it and have written a test
script
so that you can verify this on your end as well. This bug (should you
accept to
proclaim it a vaild bug) relates to the autoglobal $_SESSION. More
specifically, $_SESSION can be broken so that the values set in it are
not
actually saved. First, lets see how it can be broken:
<?php
session_start();
echo 'Before session modifications (what got saved to
disk):<br><pre>';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
global $_SESSION;
$_SESSION['foobar'] = 2;
echo '</pre>After session modifications:<br><pre>';
var_dump($_SESSION);
?>
When you run this, and then hit reload (since you must run it at least
twice to
see what actually got saved by session), the browser will output this:
Before session modifications (what got saved to disk):
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
int(2)
}
So, you can see that the line "global $_SESSION;" essentially breaks
session -
the "2" never gets saved to disk. If we comment out "global
$_SESSION;", it
works and the browser outputs this (after you hit reload twice):
Before session modifications:
array(1) {
["foobar"]=>
int(2)
}
After session modifications:
array(1) {
["foobar"]=>
int(2)
}
So now you are asking that is interesting, but why would you ever want
to
"global" an autoglobal. Good question! There would be no purpose in
doing this
since $_SESSION is always in scope. Well, this bug presented itself to
me in
an application where there was a reference to a portion of $_SESSION.
Since
the application is over 5000 lines of code, we will view a highly
condensed
test version of this:
<?php
session_start();
echo 'Before session modifications:<br><pre>';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
$foobar = $_SESSION['foobar'];
global $foobar;
$foobar = 3;
echo '</pre>After session modifications:<br><pre>';
var_dump($_SESSION);
?>
Outputs:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
&int(1)
}
And if we comment out "global $foobar;" we get:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
&int(3)
}
This is the behavior we would expect with a reference given the output
we saw in
the earlier example. But why would we run "global $foobar;" if it is
already
in scope? In my application, other developers use the code for
purposes of
building other applications. Since I don't know what scope they are
including
my code in, I have to assume it is NOT in global scope and therefore
run
"global" on some variables that I will need. In this sort of situation
it makes
sense to call "global" just to make sure that you have what you need.
The
problem is that if they did include it in global scope that it busts
session!!!
Anyways, I look forward to your response. I have already implemented
a
workaround to this problem but think it is important that the PHP
QA/BUG teams
are aware of this issue.
Thank You for you time - everyone appreciates the work that you do for
PHP
P.S. My configure line is:
'./configure' '--enable-memory-limit' '--with-mysql=/usr/local/mysql'
'--with-zlib' '--with-apache=../apache_1.3.27'
'--enable-inline-optimization' '--with-curl=/usr/local'
'--with-mcrypt=/usr/local'
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=20728&edit=1
