|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #34542 register_long_arrays causes $_SESSIONS vars to disappear
Submitted: 2005-09-18 15:34 UTC Modified: 2007-07-25 14:38 UTC
Avg. Score:4.5 ± 0.8
Reproduced:10 of 10 (100.0%)
Same Version:3 (30.0%)
Same OS:3 (30.0%)
From: marcus dot uy at virtualthinking dot com Assigned:
Status: Not a bug Package: Session related
PHP Version: 5.1.0RC4, 5.2.0 OS: ALL
Private report: No CVE-ID: None
 [2005-09-18 15:34 UTC] marcus dot uy at virtualthinking dot com

I have read through some earlier bug posts regarding similar-ish in later versions of php4 and early versions of php5.

I want to report that this bug persists in version 5.0.4, 5.0.5, as well as 5.1.0rc1 too.

Setting "register_long_arrays=off" causes $_SESSION to break, but in a very unusual way.

For some reason putting 4 or 5 small items in the sessions array is fine (which is why most tests can pass), but putting more data or more items in the sessions array prevents the data from being written to the session file.  You get a zero-length file and the session fails.

There is no error that faults or reports from this.

I haven't really measured the "breaking point", but it is real and I can consistently reproduce it on my system (the code is way too long to post here).

I note that php.ini doesn't seem to indicate the default status of this setting, but if "off" is the default value then this bug does not seem to affect linux versions of php.

Turning "on" register_long_arrays in php.ini restores full functionality.  I suppose then, that this would be the near term work around.

Reproduce code:
 session_start ();
 $_SESSION['login']       = "";
 $_SESSION['password']    = "blahblahblah";
 $_SESSION['memory']      = "abcdefghijklmnopqrstuvwxyz";
 $_SESSION['userid']      = 1;
 $_SESSION['userlevel']   = 10;
 $_SESSION['usergroup']   = -1;
 $_SESSION['accesslevel'] = 10;
 $_SESSION['accessgroup'] = -1;
 $_SESSION['auth']        = "NATIVE";
 $_SESSION['auth_ip']     = "";

 echo ("<a href=\"/page2.php?".SID."\">Test Session</a>");

 session_start ();
 print_r ($_SESSION);

Expected result:
 ['login']       = "";
 ['password']    = "blahblahblah";
 ['memory']      = "abcdefghijklmnopqrstuvwxyz";
 ['userid']      = 1;
 ['userlevel']   = 10;
 ['usergroup']   = -1;
 ['accesslevel'] = 10;
 ['accessgroup'] = -1;
 ['auth']        = "NATIVE";
 ['auth_ip']     = "";

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-18 22:07 UTC]
Please try using this CVS snapshot:
For Windows:

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)

 [2005-09-19 12:38 UTC] marcus dot uy at virtualthinking dot com
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.
 [2005-09-19 13:47 UTC]
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.

 [2005-11-03 09:36 UTC] marcus at synchromedia dot co dot uk
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.
 [2005-11-03 16:47 UTC] marcus dot uy at virtualthinking dot com
Hi, I think somebody else has a related problem with a workable test case.
 [2005-11-09 23:43 UTC] mail at lenzw dot de
see Bug #33811 for a reproduction code.
 [2006-11-28 22:35 UTC] marcus dot uy at virtualthinking dot com
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.
 [2006-11-28 22:48 UTC]
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.
 [2006-11-29 01:19 UTC] marcus dot uy at virtualthinking dot com
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.
 [2006-11-29 10:08 UTC]
First of all, please remove/disable mod_security.
 [2006-11-29 12:15 UTC] marcus dot uy at virtualthinking dot com
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?


$_SESSION => can show up during the run
$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???).
 [2006-12-05 15:12 UTC] marcus dot uy at virtualthinking dot com
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.
 [2006-12-05 15:37 UTC]
>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.
 [2007-07-25 04:54 UTC] marcus dot uy at virtualthinking dot com

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.
 [2007-07-25 14:38 UTC]
Yes, $_SESSION is special. RTM:
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sat Oct 01 15:03:57 2022 UTC