|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15983 session variables lost between pages
Submitted: 2002-03-10 09:14 UTC Modified: 2002-10-15 10:18 UTC
Avg. Score:4.9 ± 0.4
Reproduced:38 of 39 (97.4%)
Same Version:28 (73.7%)
Same OS:10 (26.3%)
From: sl at scrooge dot dk Assigned: sascha (profile)
Status: Closed Package: Session related
PHP Version: 4.1.2 and 4.2.0 OS: Debian/Linux mips platform
Private report: No CVE-ID: None
 [2002-03-10 09:14 UTC] sl at scrooge dot dk
The session variables are lost between pages.

For example:
$test = "Hello world";

echo $test;

The output on page two is the empty string.

A look at the sess_* in /tmp show that it contain the variable and the value after a request on session1.php.

After a request on session2.php the file is empty.

This error shows up in php 4.1.1 and 4.1.2.

In version 4.0.6 everything works as it is suppose to.

uname --all:
Linux indy01 2.4.16 #1 Sun Dec 16 16:38:44 CET 2001 mips unknown

gcc --version:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-03-12 20:52 UTC] php at bradandkristin dot com
I've had the same issue (see bug 15822, which was marked as a duplicate, though nobody saw fit to tell me what it was a duplicate of).

Anyone have a work-around?
 [2002-03-18 11:16 UTC] phpbug at ehrlichorg dot com
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.
 [2002-04-02 09:48 UTC]
Could you try 4.2.0RC1?
Please visit for it.
 [2002-04-05 03:50 UTC] sl at scrooge dot dk
Even in PHP 4.2.0RC1 the bug is still there.

Nothing is changed.

Best regards,

 [2002-04-12 05:23 UTC] achim at ddd dot de
what about this workaround:

--- page #1 ---
$_SESSION["test"] = "some value";

--- page #2 ---
print $_SESSION["test"];

this works well for us.

 [2002-04-24 09:55 UTC] gearond at cvc dot net
These two pages, s*1.php and s*2.php are called consecutively, separately by the same browser with the SID in the cookie?

I thought sessions had to be accessed using a SID. At least, that is the way I believe PHPLib does it, and PHP 4.x.x is supposed to be exhibiting similar behavior, right?

If one script is including the other script, I don't know hwo that would work.
 [2002-04-24 18:19 UTC]
Reopen if this script does not work for you with PHP 4.2.0:


if(!isset($_SESSION['test'])) {
  $_SESSION['test'] = 0;
echo $_SESSION['test']++;


It works fine here..(reloading the page increases the count)


 [2002-04-25 17:30 UTC] sl at scrooge dot dk

 [2002-04-26 21:07 UTC]
This _might_ be related to some fixes made recently..
Can you try with the latest CVS snapshot from please?

 [2002-04-28 07:31 UTC] sl at scrooge dot dk

 [2002-04-30 13:47 UTC] herrington at topiksolutions dot com
This bug is killing me. Anyone tried 4.1.2 RC4 ?  Otherwise, I am rolling back to 4.06. Don't really have time to do the workarounds....
 [2002-05-29 15:59 UTC] foosnb at nc dot rr dot com
I'm working with win version 4.1.2, and while the very first example's code worked find for me (printed 'Hello world' as expected), the test script from did not.

From my testing, it appears as though using $_SESSION just doesn't register a value with the session, although it maintains any changes to a variable once it has been registered with the session.

If instead of,


if(!isset($_SESSION['test'])) {
  $_SESSION['test'] = 0;
echo $_SESSION['test']++;


you use,


if(!isset($_SESSION['test'])) {
 $test = 0;
echo $_SESSION['test']++;


 the script will increment the variable just fine. But because $_SESSION['test'] = 0; doesn't set/register the variable the first time, each time you refresh you will find yourself stuck in the if statement, and the value still stuck at 0.

 -- foos
 [2002-08-21 07:48 UTC] pratesi at telug dot it
I am affected by just the same problem on Debian Woody PPC
with PHP 4.1.2.

I also get a sigsegv:
gdb /usr/sbin/apache
(gdb) run -X
Program received signal SIGSEGV, Segmentation fault.
0x0f3e61d8 in zend_hash_get_current_key_ex () from /usr/lib/apache/1.3/
It seems that this sigsegv does not occur with PHP 4.2.2.

Using session.save_path = mm seems to workaround with
PHP 4.1.2, but I would prefer to avoid using libmm,
which now is a dead project; moreover, this workaround
is rather awkful, as sessions get lost if Apache
is restarted (e.g. to let it reread httpd.conf after
some changes).
BTW, which other options are available apart from
session.save_path = files
session.save_path = mm

I fear that this will force me to downgrade to PHP 4.0.6,
but I cannot keep the server outdated for too much months
 [2002-08-22 06:33 UTC] pratesi at telug dot it
The following patch seems to workaround the problem for me,
on Debian Woody PPC:

--- ext/session/mod_files.c.orig        Tue Apr 23 20:10:49 2002
+++ ext/session/mod_files.c     Thu Aug 22 11:41:05 2002
@@ -255,12 +255,16 @@
        data->st_size = *vallen = sbuf.st_size;
        *val = emalloc(sbuf.st_size);

 #ifdef HAVE_PREAD
        n = pread(data->fd, *val, sbuf.st_size, 0);
        lseek(data->fd, 0, SEEK_SET);
        n = read(data->fd, *val, sbuf.st_size);
        if (n != sbuf.st_size) {
                return FAILURE;

I.e., use of the read instead of pread seems to fix
the problem.
I wonder if this is a PHP bug (maybe endianess?)
or a glibc bug.
 [2002-08-27 11:33 UTC] niimai at tiscali dot it
It seems that also on WinXP, when I do redirects between pages, I experience the same problem, using header("Location: URL");.
 [2002-08-28 13:07 UTC] kt at mconline dot dk
Im using RH7.3 - PHP 4.1.2 and i have all the mentioned symptoms.

When using header for redir i seem to loose the session vars.

I seem to be stuck here 

Looking forward to hear any suggestions :)


 [2002-08-29 11:34 UTC] pratesi at telug dot it
RH 7.3 on i386???
Noooo.... do you have enabled cookies? :-)

Apart from joking, the problem we are mentioning
seems to be strictly related to non-i386 platforms,
while I do not have any problem on both Debian Woody
and RH 7.3, both with PHP 4.1 and 4.2.
I have problems only on PPC (I still haven't had time
to test on Debian Sparc, I should try in september),
but the workaround that I have mentioned seems to be
correctly working since from many days on my new server :-)

BTW, the workaround that I'm using corresponds to using
the same code that it was used in PHP 4.0 and that worked
for me also on Debian Sparc and on Linux PPC.
 [2002-08-29 12:14 UTC] neuj60 at yahoo dot de
Look at these examples, refresh the same file:

Example 1 works fine:
print "<p>variable={$HTTP_SESSION_VARS['AVAR']}</p>";

Example 2 doesn't work correctly:
prints always "count=1" and thats stored in the session file:
GLOBAL $count;
print "<p>count=$count</p>";

For scalars Ex. 1 would be ok, but how to deal with objects?

I'm using PHP 4.2.2 (same was with 4.2.1) on Windows2000.
 [2002-08-29 16:30 UTC]
The problem with the suggested work around is fairly straight forward.

from the ext/session/config.m4:
if test "$PHP_SESSION" != "no"; then
  AC_CHECK_FUNCS(pread pwrite)

This asks libtool/autoconf to check the system for the functions pread and pwrite.  If they are found by libtool/autoconf (mostly autoconf), the HAVE_PREAD and HAVE_PWRITE flags are set.  If your work around is actually working, it would suggest to me that pread doesn't work properly on this non-i386 machines.  

Is there any chance you can look into the pread/pwrite functionality of these non-i386 machines?
 [2002-08-30 06:54 UTC] pratesi at telug dot it
I can make all tests that you want as I'm the sys admin
of the computers at hand.
But if tests affect the use of apache and php, a bit of
patience is needed, as the computer currently using
that workaround is a production server, hence I need
to install and set up an unsed computer of the rack.
An analogous consideration holds true for the Sparc
I'm using :-)
If you prefer, we can continue with private mailing.
Which tests should I perform on the pread() ?
Should I open a bug report for glibc 2.2 ?

Thank you for your time.
 [2002-08-30 10:06 UTC] sl at scrooge dot dk
I will try to make some test this weekend om the MIPS platform.
 [2002-08-30 12:14 UTC]
Can any of you check your php_config.h file and see if the HAVE_PREAD variable is defined?  
 [2002-08-30 14:45 UTC] pratesi at telug dot it
Debian Woody 3.0r0 PPC, PHP 4.2.2

bash$ find . -name php_config.h

In all these 3 files, HAVE_PREAD is defined and set to 1:

/* Define if you have the pread function.  */
#define HAVE_PREAD 1

BTW, I could try to compile PHP 4.1 or 4.2 on a Linux PPC
box based on glibc 2.1 and check if the same problem
occurs also with glibc 2.1.
Could this check be useful?
 [2002-09-03 13:39 UTC] pratesi at telug dot it
I have found some messages that could reply to our issue;
the second is a reply written by Linus Torvalds:

In practice, for what I'm able to understand of these messages,
it seems that, on non-i386 platforms, glibc and the linux kernel
could "disagree" about the implementation of pread() and then
that the use of pread() on linux + glibc can fail on non-i386 platforms.

Some other messages about this topic:                                                                                                                                    

And finally:

where it is written that it is a glibc bug, fixed in the CVS.

I suppose that future Linux distributions will not be affected 
by this problem, but, IMVVVHO, for safety reasons, currently
the use of pread() should be avoided on non-i386 Linux platforms,
and this should solve this issue.
 [2002-09-04 08:43 UTC]
There is now a patch submitted to CVS, test the latest out and see if it works better for you. 
 [2002-09-09 18:23 UTC] pratesi at telug dot it
I have downloaded the snapshot php4-200209091500;
when I run the configure on Debian Woody PPC, I read:

Configuring extensions
checking for pread... yes
checking for pwrite... yes
checking whether pwrite works... yes
checking whether pread works... yes

but maybe you want that instead, on this platform,
the check returns "no" for
"checking whether pwrite works..."
and for
"checking whether pread works..."
don't you?
 [2002-09-10 07:06 UTC] sl at scrooge dot dk

 [2002-09-10 07:35 UTC]
Please try using this CVS snapshot:
For Windows:

In 4.2.3, there is no more PREAD functionality.  Please try that and see if these problems continue.

I took out the PREAD functionality in cvs HEAD, but sascha has re-added.  He has also placed some further tests to ensure that it works.... so try that as well, so we can see if thats stable.  

My local test box doesn't support it, so...
 [2002-09-10 10:28 UTC] sl at scrooge dot dk

 [2002-09-10 15:24 UTC]
Which patch still fails?  4.2.3 or CVS HEAD?
 [2002-09-11 01:23 UTC] sl at scrooge dot dk

 [2002-09-11 08:34 UTC] pratesi at telug dot it
Still the same problem with the snapshot php4-200209110300:
checking for pread... (cached) yes
checking for pwrite... yes
checking whether pwrite works... yes
checking whether pread works... yes

I have not tried with PHP 4.2.3, but I have seen that,
for version 4.2.3, the code that I commented out in 4.2.2
has been removed, hence I am rather confident that 4.2.3
is OK on Debian Woody PPC :-)
 [2002-09-11 09:40 UTC]
Since confidence is high, I'm marking as closed.  The PREAD check is still in effect yes, I didn't remove that.

It would be nice if you could test the latest snapshot, as the PREAD was re-introduced, but with added protective measures.
 [2002-09-12 16:03 UTC] sl at scrooge dot dk

 [2002-09-12 16:06 UTC]
Assigning to sascha as he was busy with it.

 [2002-09-12 16:15 UTC]
I'd like to see this fixed for 4.3.0.  Right now the simple answer is to remove PREAD (again).  
 [2002-09-25 06:17 UTC]
If you want us to avoid using certain features of your platform, then you need to provide specific testcases. We will use these testcases to determine whether pread/pwrite work on a platform.

Currently, we use this for pread (after echo test > conftest_in):

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

main() { char buf[3]; return !(pread(open("conftest_in", O_RDONLY), buf, 2, 0) == 2);

And this for pwrite:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

main() { return !(pwrite(open("conftest_in", O_WRONLY|O_CREAT, 0600), "hi", 2, 0) == 2);

 [2002-09-25 16:36 UTC]
Sascha it's not a problem of using a feature on their system, it's a problem that the functionality is broken on their end.  Your test, while possibly being correct, doesn't have a way to check this.... and I don't really think there is a way.  

As of this moment I'm not even sure if there is a released version with it working.  

Marking this as open, as there is nothing the end user can comment back on to this.  
 [2002-09-26 11:18 UTC] pratesi at telug dot it
I cannot ensure you that 4.2.3 solves the problem
as I still have not upgraded from version 4.2.2,
but I am sure that it works, as the only change needed
to make things work for me has been the removal
of the lines that have been kindly removed
for version 4.2.3 (many thanks).
BTW, the same workaround has been backported on the
Debian Woody's 4.1.2 packages, and in a short time
I could check if the fix works on Woody for Sparc.
I also point out that, as this problem seems due to a glibc
bug and not to errors in the PHP code, I have submitted
a bug report to the Debian's glibc maintainer, asking him
to backport a fix for the glibc packages; hence, hopefully,
in the future, updated Linux distributions should have
a fixed glibc package and you could finally ignore this
problem and restore the code using pread().

But I would like to submit you a simple (and perhaps
stupid) suggestion.
Maybe you could provide a ./configure option to explicitly
disable the use of pread() and pwrite(), i.e.
./configure --no-pread --no-pwrite
In this case, you could release without problems the code
using pread() and pwrite(); the person that compiles and/or
packages PHP has the possibility of disabling pread()
and/or pwrite() if things do not work... is this
a bad idea?
 [2002-09-28 15:19 UTC] pratesi at telug dot it
PHP 4.2.3 works for me on Debian Woody PowerPC.
 [2002-10-01 14:29 UTC]
I'm closing this bug for now, use of pread/pwrite has been suspended.
 [2002-10-13 02:32 UTC] pratesi at telug dot it
PHP 4.2.3 works for me also on Debian Woody Sparc, even
though I am using the CGI version and I'm not able to use
PHP as a module, as Apache refuses to start... it seems
that there is some sort of binary incompatibility.
I have the same problem with version 4.1.2, too.
However, this seems to be a different issue, I suppose
that it is better do deal with it elsewhere, right?
 [2002-10-15 10:18 UTC] sl at scrooge dot dk

 [2002-12-31 20:24 UTC] oscar at cerecita dot com SOLUTION
One thing easy thing. I used POST, I used GET, and variables were lost. I thought, why phpMyAdmin is working? I did check their code and found at the beginning of the index.php page the use of:
require ('yourpath/libraries/grab_globals.lib.php');

I dont know what it does, but every thing is working fine now in all servers, with simple code, not workarounds.

 [2010-10-18 07:28 UTC] tashi dot wangchuk at itechnologies dot bt
I have a user session which only works on the localhost. The session value gets 
disappeared when i access over the network. I am doubting whether it is a server 
configuration problem.

Did any one face such a problem? If you have a solution I am very much in need.
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC