ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
Responding to albert.
My system also needed to have session.save_handler set to user for load
balancing. However, I tried using files instead and at first I thought
it worked fine but it turned out it still crashed, only less often and
at different points. (Previously code output always stopped at
specific spots when it crashed and only on some pages, this just
changed the point at which it would crash and other pages that before
had no problems didn't appear correctly.
Some have suggested they removed sessions all together and still had
the problem and others claim the problems stop if sessions are not
used. (Maybe there is two completely different bugs causing similar
problems).
It seems as if this bug has nothing that anyone has been able to narrow
down as what causes the problem.
Besides apache crashing (Segmentation fault)I have noticed that other
small things don't opperate properly since version 4.0.6 that should.
Here are two other things I've seen give problems and confirmed through
test scripts.
4.2.x (or 4.3.x) unserialize() does not recognizing values set by
serialize() in PHP 4.0.x. My system stores arrays using the
serialize() function into a database (such as a color scheme). When I
upgrade to 4.2.x or new snaps, when those strings are pulled from the
database, the unserialize() function will gives an error that it
couldn't read the string (this is not a magic_quote issue as settings
are the same).
Session variable values getting corrupted:
For example at one point I had a transparent graphic shim.gif used on a
page to keep columns widths in line. That graphic was moved to a new
location but a php's script was not updated from <img src="shim.gif> to
<img src="/images/shim.gif">. This meant the HTML that PHP returned to
the visitors browser had a simple invalid link in it and the page
should load normally with just an empty placeholder where the image
shim.gif was to be. However, even though this did happen it also did
mess up session variable values. A simple test created that had the
HTML code with the invalid location for shim.gif in the image tag along
with the lines:
echo $HTTP_SERVER_VARS['PHP_SELF'].'<br>';
$HTTP_SESSION_VAR['lastpage']=$HTTP_SERVER_VARS['PHP_SELF'];
echo $HTTP_SERVER_VARS['PHP_SELF'].'<br>';
would output correctly:
pagename.php
pagename.php
BUT the session $HTTP_SESSION_VAR['lastpage'] upon the next page load
would be equal to 'shim.gif' and not 'pagename.php' like you'd expect.
So even though $HTTP_SERVER_VARS['PHP_SELF'] returned (and must have
set the correct value), setting it into a session changed the value of
it.
These problems did not happen in version 4.0.6 or older, so they may
have something to do with the bug of shutting down apache but I don't
know enough of how PHP is written to really know.
Hope this helps.
Previous Comments:
------------------------------------------------------------------------
[2002-03-19 10:03:48] [EMAIL PROTECTED]
Check out bug-report #15940, talking about propably the same problems
there
------------------------------------------------------------------------
[2002-03-19 10:00:27] [EMAIL PROTECTED]
Read the whole thread, concluded that I've got the same problems as
described by jay1
First we thought that it maybe was an Apacheproblem, so we installed an
older version than 1.3.23, namely 1.3.20
This didn't help, same bugs appeared.
Fiddled around with fopen, nothing there.
Read this thread and came to the idea to set session.save_handler to
files instead of user (wich setting actually IS necesary, because we
loadbalance our site with three mirrored servers). And since then, no
problems at all.
My question now is to jay1: how is session.save_handler in your
php-config?
------------------------------------------------------------------------
[2002-03-19 06:25:29] [EMAIL PROTECTED]
My problem isn't ftp-related either.
------------------------------------------------------------------------
[2002-03-18 13:55:46] [EMAIL PROTECTED]
My problems are definately not ftp, I run all my scripts first here on
my local test server where they are created in the first place. My
scripts ran fine on PHP4.0.6 or older but not properly on any new
version since then.
------------------------------------------------------------------------
[2002-03-18 07:57:53] [EMAIL PROTECTED]
Well it looks like I isolated the problem... and it's not PHP related.
The FTP package I've been using has been truncating files that it has
been sending to our server for some reason. I only just discovered
this today as it did it to a non-PHP document that I sent (one of only
a few).
I've changed to another FTP package and sent the PHP docs I was having
trouble with to our server (RH 7.2/Apache 1.3.20/PHP 4.0.6) and they
ran OK. I'm not sure whether it was an FTP client or server problem
(client more likely, but maybe clients are having problems dumping php
files onto a specific FTP server build?)
The FTPD we're running is WU FTPD 2.6.1 - others with this problem
might want to check this isn't happening to their too.
------------------------------------------------------------------------
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/14529
--
Edit this bug report at http://bugs.php.net/?id=14529&edit=1
