Just wanted to confirm I also experienced this problem after upgrading to 4.1.2 for the security fix, so it's not an option to go back to an older version of PHP.

The suggested $_SESSION[S][X] work around fixed my shopping cart but this is going to be a huge chore to fix the entire site. 

Is there an ETA on this fix?

Re: nospam.ricko@garagegames.com 
FYI, The code I'm working with uses a single session array variable (with many elements) and a library routine to do page jumps. Consequently I was able to fix this problem on all my pages by adding one line of code to the pagejump library routine.

I experienced a similar problem (PHP 4.1.2, Linux 2.2.19-6.2.11)

Works:
onepage.php
-----------
session_register("newvar");
$newvar = 123;
header("Location: somepage.php");

somepage.php
------------
echo $_SESSION["newvar"]; //echoes 123

Doesn't work:
onepage.php
-----------
$_SESSION["newvar"] = 123;
header("Location: somepage.php");

somepage.php
------------
echo $_SESSION["newvar"]; //"newvar" isn't set here

According to the session docs:
If you have register_globals On, you have to use session_register()
If you have register_globals Off, $_SESSION['var'] = 123 will register it

That means that you have to switch everything over to the $_ vars and turn off register_globals before sessions work correctly (because the $_REQUEST[], or user input, vars won't be available globally any more).

If I'm wrong, let me know :)

Any attempt I have made to save session variables in 4.1.2 fails now.  I can replace my php version with 4.1.1 and it works fine.  I have noticed that the session files are created in the temporary directory, but while they contain the encode session data in php 4.1.1, they are 0 byte files in php 4.1.2.  I am using IIS5.0 on Win2k.  This fails in both the CGI and ISAPI version.  I can reproduce it every time simply by stopping IIS, replacing php.exe, php4isapi.dll, php4ts.dll, and php4ts.lib, restarting IIS, and trying it.  No changes to code and no changes to php.ini.  Not even the php session manual's sample for showing the number of times you have visited a page works!!  I really want this security fix, but I can't upgrade to it if it's going to break sessions.

I do run a "slightly" (not where it really counts) modified php.ini that resembles the php.ini-recommended in almost every respect.

I think this a glaringly obvious bug and can't imagine it can't be reproduced, just try the sample - I have confirmed and reproduced this bug on THREE IIS5.0 Win2k platforms.

Here is part of what is going wrong. PHP starts out with each session variable appearing as a global and also in $_SESSION. Initially these are linked by reference (not clear how) and contain the same data. On my pages this linkage appears to get broken so the contents $GLOBALS['S']
and $_SESSION['S'] are not the same. $GLOBALS contains the latest data, $_SESSION contains the data as of the start of the page. Consequently changes to the $_SESSION variable are not being saved between pages.

My work around is to use the following at the end of each page for $S:

	if ( !($_SESSION['S'] === $S) )
		$_SESSION['S'] = $S;

This updates the contents of the $_SESSION variable if it is not longer the same as the global.

Based on a comment from one of the developers, the problem may relate to having a global declaration for a session variable that appears outside a function scope. I have these declarations on each of my pages because PHP used to require them.

Interesting workaround:

session_register("lastaction");
session_register("userip");
session_register("lines"); // etc etc
$HTTP_SESSION_VARS["xx"] = "Anything"; // this is the magic bit

Although xx isn't a registered session var, and doesn't get stored in the session, it seems to stimulate PHP to update the session vars in the file!

With that addition, my apps now work fine under 4.1.2.. (Win 2k, Apache 1.3.23)

John

It looks like the PHP 4.1.2 forgot to call session_write_close() by default. I added this call at the end of my program, and solved this session problem.

Hmm. It sounds like PHP is segfaulting. (Or bailing out without proper shutdown)
If you are having segfualts, could you build PHP with --enable-debug and send the backtrace?

PHP Does not appear to be seg faulting; nothing in the logs indicates that type of error.

Do you use MySQL?

Yes, we are using MySQL 3.23.38 in the application. However, the session.save_handler is files. 

We were using the same version of MySQL with PHP 4.0.2.

Could you limit size of max text size returned from MySQL?
Does it help?

Sorry, I don't see where I would limit size of max text size returned from MySQL or what you are looking for. Please clarify.

The applications that are not working are not using large text fields. Most are defined as TINYTEXT and TEXT. There are a couole of columns defined as MEDIUMTEXT (due to misunderstanding of field types) but the contents are less than 4000 bytes.

There is bug report for MySQL.
After serval database operation, calling heade() crashes PHP for some reason according to the bug report.

Anyway, I don't use MySQL and I don't have this problem.
We need backtrace or need where/how PHP is bailing out.

Build with --enable-debug and check what is going to with debugger.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

MySQL is not the problem. We have not changed MySQL versions, just the PHP version. 

Some of the cases that fail do not do any database operations. They change a context variable and page jump (via header()) to another PHP page.

If this were a MySQL problem, the work around I described above would not fix it.

The problem appears to be with PHP and the management of session variables.

Note: Status should be changed to Open but the only options I have are No Feedback or Closed.

Does this happen with latest CVS (stable branch) snapshot ?

http://snaps.php.net/php4-STABLE-latest.tar.gz

--Jani

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

using session_write_close(); after seeting the session variable solved it for me.

NBMNMNBMBNMBN