Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

I can't reproduce this on either Linux or Windows.
(using sessions with cookies, of course, passing session ids in the URL is not wise)

Hi just tried it with the CVS versions to popinted me to.  No dice.

Same problem.  After the session is created as a zero-length file and updating $_SESSION in the script does nothing to change this.

The values are accessible during the first run, and when re-read on subsequent runs, understandably return an empty $_SESSION array.

FYI, my application is split into a public http system and a private https system.  The session sticks in the http session, but as noted earlier, the number of session values used is significantly less than after a user has logged in the https session.

I allow the script to generate a new SID for the https session as I do not need to pass over the values, and it is here that the values do not stick.

Both the http and https sites share an *indentical* code base so it's not a program error.

Erm, to be honest the code I posted is cut down to allow for it to be a reasonable length.  It incorporates the essentials of the problem, but perhaps not the full environment.

It still needs the register_long_arrays to be "on" before it will work.

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

I think I'm seeing this same bug in 5.1.0RC4. I'm not 
getting exactly the same symptom, but it's close. I'm 
finding that session files are created no problem, but when 
I change values in $_SESSION, the changes are not saved, 
even if I use session_write_close(). I've set up a small 
test case that is storing and changing exactly what I'm 
doing in my project and it doesn't happen, so I don't think 
it's a problem with the contents of the session. I also 
wrote a test that stuffed 5000 strings into $_SESSION and 
that worked ok too.
Like the original bug report, it all works fine if I leave 
register_long_arrays turned on, even though I'm not using 
them anywhere in my code, or in libraries that I'm using.
What I would like to do is do a trace with xdebug and look 
at everything that involves sessions, but I can't at present 
because xdebug-cvs won't run under 5.1.0RC4.

Hi, I think somebody else has a related problem with a workable test case.

see Bug #33811 for a reproduction code.

This bug is still there in 5.2.0.

BTW My environment does not use session cookies.  I use the session passed via URL.  The reason is that my code overcomes the problems associated with URL hijacking in-code, rather than depending on session cookies that could also get hijacked.

The error stands.

I swear that it is real.

And, frankly, there seems to be many, many scripts and users that are reporting similar session issues.  I don't think that we could all be wrong.

Cannot reproduce, doesn't matter what is the value of register_long_arrays. Please make sure you don't have any firewalls or zend_extension's which might affect it.

Dev/Tester.  Please tell us what your setup is.  Mine is as follows:

XPPro SP2, Apache 2.2.3, mod_security 2.0.4, PHP5.2.0

Settings as per recommended for performance.

Sessions configured to use URL, NOT cookies.

Sessions are being stored in C:\temp\sessiondata

When register_long_arrays is set to "off", Session data is created in the script on first execute (print_r($_SESSION), dumps correctly), but not saved to session file (e.g. sess_34r234r234r234r234r234, is zero-length)

When register_long_arrays is set to "on", Session data is created in the script on first execute (print_r($_SESSION), dumps correctly), and is saved to session file (e.g. sess_34r234r234r234r234r234, is non-zero-length)

The code does not use *any* HTTP_*_VARS... anywhere.  Only $_ENV, $_GET, $_POST, and $_SESSION.  $_COOKIES is *not* used anywhere.

First of all, please remove/disable mod_security.

mod_security removed.  Behaviour of PHP is still the same as my previous post.

I have tested the same php.ini file on a separate linux server (with path names adjusted for linux) that I own and it works with register_long_arrays=off in the expected manner as documented.

The same settings on windows fail to work as noted earlier.

I cannot verify this, but is there some internal reference or dependency in the session subsystem that uses the old long array vars/buffer as the input source for the data that is written to the session file?

Hence:

$_SESSION => can show up during the run
...but...
$HTTP_SESSION_VAR => written to disk, and thus empty

Any chance?  Was discussing fault scenarios with a friend and this came up as a plausible case that would result in this kind of oddity (a difference in how the windows and linux compilers work might account for the difference in behaviour on different platforms???).

Just a quick update.  A correction on the Linux settings.  Like on Windows, "register_long_arrays=On" causes the described problem with the session too.

My bad.  Did not notice that the option was commented out.

>Like on Windows, "register_long_arrays=On" causes the
> described problem with the session too.
No, it doesn't.
With register_long_arrays=On I get the same result, as with Off. It works perfectly fine.

I guess you have some kind of broken browser and/or some combination of Apache modules or PHP/Zend extensions, which cause it. By the way, you didn't answer my question on zend_extensions.

Hi,

I have resolved this issue.  It's not that the long arrays that is broken, but that $_SESSION has some unexpected behaviours.

It turns out that $_SESSION is NOT really a normal array.  If you assign a bunch of values to $_SESSION as an array, e.g.:

$_SESSION = array ("value1", "value2", "value3");

It destroy's the "magic" of $_SESSION and session becomes a standard array (that vanishes on script exit), thus it does not save settings as expected.

There have been some similar complaints in other bug reports.  The discussion breaks down into two camps:

1. This is a feature, so don't allocate the array
2. This fails the test of "least surprise", behaviour should be "corrected"

Ah well, it works now, and I know why, so that's what matters.

Yes, $_SESSION is special. RTM: http://www.php.net/session