ID: 20449
Comment by: php dot bugs dot krishaven at spamgourmet dot com
Reported By: josh at zebotech dot com
Status: Open
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
My session problems appear to all be caused by the fact that
$array1=$array2 doesn't do a "deep copy" as described in bugs:
http://bugs.php.net/bug.php?id=8130
http://bugs.php.net/bug.php?id=21288
http://bugs.php.net/bug.php?id=20993
Personally, I don't think that the previous dismissal of the problem
with "This will not be fixed anytime soon. It is a deep seated problem
in the implementation and fixing it would cause speed problems and
numerous other problems," or considering it a documentation problem are
appropriate responses. I guess I was lucky that this was causing an
apache segfault, or who knows how much data this could have corrupted?
Previous Comments:
------------------------------------------------------------------------
[2003-05-07 19:29:28] php dot bugs dot krishaven at spamgourmet dot com
Sorry, they all work under php4.2.2/Apache1.3.26. Maybe 0.0.01 of a
version makes a difference...
------------------------------------------------------------------------
[2003-05-07 19:27:18] php dot bugs dot krishaven at spamgourmet dot com
Okay, new data. Abstracted from our address details page. We fetch
four sets of address details this way and make a copy for clients to
edit.
*This Fails*
$old=mysql_fetch_array($result);
$new=$old;
session_register("old");
session_register("new");
*This Works*
$old=mysql_fetch_array($result);
session_register("old");
*This Works*
$old=mysql_fetch_row($result);
$new=$old;
session_register("old");
session_register("new");
*This Works*
$old=mysql_fetch_array($result);
mysql_data_seek($result,0);
$new=mysql_fetch_array($result);
session_register("old");
session_register("new");
They all work under php4.2.2/Apache1.3.27.
It appears there's something wrong with $array1=$array2 when its an
associative array from an SQL fetch, but it only shows up when you try
to save it as a session variable.
------------------------------------------------------------------------
[2003-05-07 03:08:48] php dot bugs dot krishaven at spamgourment dot
com
Okay, I'm replicating this problem on a parallel installation of 4.3.1
(http://gw.cic.wa.edu.au:81/test.php). Here's the reproducible
behaviour;
* Associative arrays break, enumerated do not. Non-array session
variables do not cause the problem.
* The files landing in /tmp are corrupted, ignore my previous comment
that they weren't.
* Doing a session_write_close(); then print_r($_SESSION); on the page
that registers the associative arrays (the time it registers them) will
show an uncorrupted $_SESSION.
* The next page that reads that session will show a corrupted
$_SESSION. Typically the 5th and 6th arrays (remember, the page that
I'm using to test adds eight arrays to the session) gain an extra
dimension made up of corrupted entries from the 7th or 8th arrays (2 is
a copy of 1, 4 is a copy of 3, etc)
* The first time you load the corrupt session details there are
typically only alphanumeric characters. Subsequent reloads tend to
show control characters where the problem's occuring.
* Apache crashes on the first load of the corrupted session data, not
on the write.
* I have made some very complicated associative arrays then serialised
and unserialized them without any problems. The problem on appears to
occur with sessions.
Note: This installation will be upgraded to the latest available
version whenever possible. The phpinfo() page may not match what I've
just reported.
------------------------------------------------------------------------
[2003-05-06 03:38:53] php dot bugs dot krishaven at spamgourmet dot com
One of our sites has this problem. A phpinfo() page for them is at:
http://www.myibt.vic.edu.au/help.php It's
runnning Redhat 7.3, PHP
Version 4.3.0 and Apache/1.3.27
Note: This is a production system and may get downgraded in the next
few days if we can't resolve this problem.
We have a page that sets eight associative arrays as session variables.
It *always* falls over (apache segfaults) when you set all eight. The
session corrupts and no other page ever loads until you kill the
session or manage to unset the arrays. Sometimes if you only set one
or two associative arrays, it survives. However, if you set only
enumerated arrays (mysql_fetch_row instead of mysql_fetch_array) you
can set as many as you want (we've tested up to 40 copies on just that
page) and it never fails.
When you look at the session info in /tmp it appears to be complete, so
it's as if there's a problem reading associative arrays back from
session variables. I have also set the associative arrays, then gone
to a page that doesn't depend on a valid session to work, just displays
the raw $_SESSION contents. Each refresh comes up slighly different,
but sometimes it comes back perfectly, indicating again that it's
probably a read problem not a write one.
We have some major portions of a wide circulated web system that have
been written expecting associative arrays to survive session
registration. Major things like student enrolment. While it appears
that we could re-write everything to only use enumerated arrays, we
simply do not have enough days until the next enrolment period to
manage this. By the same token we have some sites that specifically do
not want to downgrade their installations.
------------------------------------------------------------------------
[2003-03-13 17:08:29] dave at flitsservice dot nl
* PHP Version 4.2.2 (and 4.1.1)
* Apache 2.0.40 (and 1.3.23)
* Windows NT 5.1 build 2600 (Windows XP sp1)
Allright, I experience this problem also! (thnx Google). It drives me
mad, I already did a downgrade to PHP v4.1.1 without succes.
I experience the same situation as jpmarray, the page looks like it
loads, I get some HTML code and a part of my page is displayed...
Suddenly it breaks off the output showing some unfinished HTML code and
a "Page cannot be displayed" occurs.
And I'm talking of the well known phpinfo.php now! The strange thing
which someone else mentioned also here, is that it works perfectly well
with all non-IE related browsers. I tested it for example with Mozilla
1.0 and everything is working fine.
And now comes the strange part. I have another server here, running
exactly the same OS (Windows NT 5.1 build 2600) and exactly the same
installation and php.ini file (version 4.1.1) and that is working
perfectly well. The only difference is the Apache server version;
1.3.23
And I don't want to downgrade Apache unless I have too...
Oh and another thing, I tried to run phpinfo.php on different machines,
all resulting with the same problem. No go with IE and Mozilla and
Opera 7 everything looks OK...
But while I test this when I'm writing this now, I see that it isn't OK
either with other browsers... It does not result in a "page cannot be
found" error but it just unfinishes the page ending. This looks like
it's doing it at random... Sometimes stopping earlier and sometimes
near the end of the output...
Very strange! Nothing is wrong with my php maximum execution time or
something. Remember that I have two different servers with exactly the
same PHP installation...
Maybe I'll try an Apache downgrade to exclude some things out
tomorrow... First I'll get some sleep, luckily this is less critical
than the problem of Josh...
Dave Lolkes de Beer
The Netherlands
------------------------------------------------------------------------
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/20449
--
Edit this bug report at http://bugs.php.net/?id=20449&edit=1