ID: 20449
Comment by: dave at flitsservice dot nl
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:
I would like to report that I resolved my problem described earlier
here.
There is a bug in Windows 2000 and is resolved bij one of the available
service packs (I thought service pack 3).
Previous Comments:
------------------------------------------------------------------------
[2003-05-09 00:18:19] php dot bugs dot krishaven at spamgourmet dot com
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?
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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