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:
Sorry, they all work under php4.2.2/Apache1.3.26. Maybe 0.0.01 of a
version makes a difference...
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2003-01-31 14:57:30] jpmurray at hxti dot com
Hello all,
* PHP Version 4.2.3
* Apache 1.3.27
* Linux
* config: ./configure' '--with-apxs'
'--with-oci8=/usr/local/oracle/m01/app/oracle/product/8.1.7/'
'--with-openssl' '--with-curl' '--with-mysql'
I'm having this problem every day, and can reproduce at will.
Extremely frustrating.
For me it only occurs upon (successful) login to my site. Instead of
going to the php index, I get a "Page cannot be displayed". I'm using
non-cookie sessions managed by an Oracle database.
Once I am in, past the login, the error never occurs however. It seems
only to be a problem when the session is first initialized via
session_start(). After this, I pass the sid via the URL, and its
subsequently checked by the target script against the oracle db for
authenticity- No problems at all there. Does anybody else see this
problem occur only upon doing things such as logging in?
Thanks,
J. Murray
HX Technologies
------------------------------------------------------------------------
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