php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #70584 Spontanous loss of all $_SESSION variables
Submitted: 2015-09-25 15:40 UTC Modified: 2019-02-24 04:22 UTC
Votes:18
Avg. Score:3.8 ± 1.5
Reproduced:9 of 13 (69.2%)
Same Version:2 (22.2%)
Same OS:4 (44.4%)
From: buschmann at nidsa dot net Assigned: yohgaki (profile)
Status: No Feedback Package: Session related
PHP Version: 7.0.0RC3 OS: Windows
Private report: No CVE-ID: None
 [2015-09-25 15:40 UTC] buschmann at nidsa dot net
Description:
------------
We recently ported our php application to a new server and decided to go productive with php 7.
With surveying the error_logs, we observed the complete loss of all $_SESSION variables occuring about 1 to 10 times/day, independend of a specific user or session.
Since elementary configuration data are stored in $_SESSION variables, the script is unable to connect to the database and falls back to load the login script again.
The crucial variables are set only once by an include file from index.php, the login script, and never changed afterwords in the other scripts.
We didn't observe it in the test phase, and cannot test it with php 5.6.13.
It seems to occur randomly, our suspicion goes to garbage collector or similar.
Sorry, but we have no expertise in php internals.

Expected result:
----------------
preservation of all $_SESSION variables throughout the session.

Actual result:
--------------
This is a log entry of a successfull login of the user
all SAM_XXXX session variables ar set only once from an include file only included from index.php (the login screen)

[25-Sep-2015 05:01:22 Europe/Berlin] HB index.php <hidden_path>\index.php: 103 session_id= 034njrgkpk89k70ac8icqt2ad5 SESSION= Array
(
    [sqlDB] => <hidden_database>
    [SAM_CONNECTION_STRING] => <hidden_access_string>
    [SAM_PDF_TOOL] => ../fpdf/fpdf.php
    [SAM_TFPDF_TOOL] => ../tfpdf/tfpdf.php
    [SAM_TCPDF_TOOL] => ../tcpdf/tcpdf.php
    [SAM_EXDATA_PATH] => <hidden_path>/ExData/
    [SAM_EXDATA_WEB] => /cps/ExData/
    [SAM_COLL_PATH] => <hidden_path>/Collection/
    [SAM_COLL_WEB] => /cps/Collection/
    [SAM_FOTO_PATH] => <hidden_path>/cpsImg/Imgs/
    [SAM_FOTO_WEB] => /cps/cpsImg/Imgs/
    [SAM_IMGS_PATH] => ../fixImg/
    [SAM_IMGS_WEB] => /cps/fixImg/
    [sqlHost] => localhost
    [sqlUs] => postgres
    [sqlPw] => 
    [IUN] => 188
    [UN] => hidden_user
    [TEMP] => 22
    [FI] => 
    [ID] => 
    [OFF] => 3
    [FIL] => 
    [N] => 
    [ORD] => 
    [OPC] => 
    [LAST_DISABLED_SEASON] => 11
    [MAX_RELEVANCE] => 2
    [SAM_DB_TYPE] => PostgreSQL
    [CU] => Array
        (
            [1] => USD
            [2] => EUR
            [3] => CNY
            [4] => GBP
        )
--

After being connected for several hours, we get the following error at 09:46:32
The reason is, that all session variables are gone, except those initialised at the beginning of MenuPrincipal: 

[25-Sep-2015 09:46:32 Europe/Berlin] HB MAIN_MENU <hidden_path>\MenuPrincipal.php: 84 session_id= 034njrgkpk89k70ac8icqt2ad5 SESSION= Array
(
    [OPC] => 
    [ID] => 0
    [FIL] => 
    [usAccess] => Array
        (
        )

)


[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_connect():  in <hidden_path>\MenuPrincipal.php on line 88

[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_query(): No PostgreSQL link opened yet in <hidden_path>\MenuPrincipal.php on line 95

[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_query(): supplied resource is not a valid PostgreSQL link resource in <hidden_path>\MenuPrincipal.php on line 95

[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_fetch_assoc() expects parameter 1 to be resource, boolean given in <hidden_path>\MenuPrincipal.php on line 97

[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_query(): No PostgreSQL link opened yet in <hidden_path>\MenuPrincipal.php on line 370

[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_query(): supplied resource is not a valid PostgreSQL link resource in <hidden_path>\MenuPrincipal.php on line 370

[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_query(): No PostgreSQL link opened yet in <hidden_path>\MenuPrincipal.php on line 373

[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_query(): supplied resource is not a valid PostgreSQL link resource in <hidden_path>\MenuPrincipal.php on line 373

[25-Sep-2015 09:46:32 Europe/Berlin] PHP Warning:  pg_fetch_assoc() expects parameter 1 to be resource, boolean given in <hidden_path>\MenuPrincipal.php on line 380

After checking for no connection, the user is sent the login screen to log in again.
This loads all the never changed session varialbes SAM_XXXX again from the include file.

[25-Sep-2015 09:46:47 Europe/Berlin] HB index.php <hidden_path>\index.php: 103 session_id= 034njrgkpk89k70ac8icqt2ad5 SESSION= Array
(
    [OPC] => 
    [ID] => 
    [FIL] => 
    [usAccess] => Array
        (
        )

    [sqlDB] => <hidden_database>
    [SAM_CONNECTION_STRING] => <hidden_access_string>
    [SAM_PDF_TOOL] => ../fpdf/fpdf.php
    [SAM_TFPDF_TOOL] => ../tfpdf/tfpdf.php
    [SAM_TCPDF_TOOL] => ../tcpdf/tcpdf.php
    [SAM_EXDATA_PATH] => <hidden_path>ExData/
    [SAM_EXDATA_WEB] => /cps/ExData/
    [SAM_COLL_PATH] => <hidden_path>Collection/
    [SAM_COLL_WEB] => /cps/Collection/
    [SAM_FOTO_PATH] => <hidden_path>cpsImg/Imgs/
    [SAM_FOTO_WEB] => /cps/cpsImg/Imgs/
    [SAM_IMGS_PATH] => ../fixImg/
    [SAM_IMGS_WEB] => /cps/fixImg/
    [sqlHost] => localhost
    [sqlUs] => postgres
    [sqlPw] => 
    [IUN] => 188
    [UN] => <hidden_user>
    [TEMP] => 22
    [FI] => 
    [OFF] => 3
    [N] => 
    [ORD] => 
    [comodin] => 
    [LAST_DISABLED_SEASON] => 11
    [MAX_RELEVANCE] => 2
    [SAM_DB_TYPE] => PostgreSQL
    [CU] => Array
        (
            [1] => USD
            [2] => EUR
            [3] => CNY
            [4] => GBP
        )

)


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-28 14:54 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2015-09-28 14:54 UTC] ab@php.net
Thanks for the report. Were it possible to have a short reproducer, not involving pg or other unrelated functionality, as a small PHP script?

Thanks.
 [2015-09-28 21:51 UTC] buschmann at nidsa dot net
-Status: Feedback +Status: Open
 [2015-09-28 21:51 UTC] buschmann at nidsa dot net
Thanks for your attention.

I am not able to create  a reproducible test case.
I only observed it on the production System, even not on the test System.
Today, I changed the application a little to avoid unchecked unset of session variables (now: if isset () then unset ()). I continued to monitor the System, but the change did not help and I got  the same errors again a couple of times.
I checked the Session variables before any other Statement, but they were already gone just after start_session().
I am not aware of any php function which accidently called would clear all Session variables. I suppose they should be preserved until we close the session explicitely.

The Environment is Apache 2.4.16 64bit, php 7.0RC3 64bit thread safe on Win 2012R2 in a VM.

I could not reproduce it on the test machine, I suppose only the production System achieves enough load (The load on the machine is quite low, mostly idling, about 10 to 20 users logged in,machine uses 1.2 GB out of 4 GB)

I hope you are able to find a certain piece of code inside PHP where it is likely to clear all Session variables.

Thanks
 [2015-09-29 01:56 UTC] yohgaki@php.net
-Package: *General Issues +Package: Session related -Assigned To: +Assigned To: yohgaki
 [2015-09-29 01:56 UTC] yohgaki@php.net
I think you are using session_regenerate_id(true).
Try session_regenerate_id(). i.e. Without "true".
This is a known issue.
https://bugs.php.net/bug.php?id=69127
If this is not related to this, please let me know.
 [2015-09-29 02:11 UTC] yohgaki@php.net
There is a bug may be related to this.
https://bugs.php.net/bug.php?id=70013
Please use latest PHP 7.
If bug 70013 is the cause, please close this one. Thank you.
 [2015-09-29 06:33 UTC] buschmann at nidsa dot net
I checked the whole code base of our application and only found 3 references relying to sessions:
session_start() on every script
session_cache_limiter('must-revalidate'); on the very beginning of all PDF generating scripts
session_id() in my debug code.

I have no call to session_regenerate_id().

I left all session related configuration parameters at default.
Here is an extract from info.php on the production machine in txt format
session

Session Support	enabled
Registered save handlers	files user
Registered serializer handlers	php_serialize php php_binary wddx
Directive	Local Value	Master Value
session.auto_start	Off	Off
session.cache_expire	180	180
session.cache_limiter	nocache	nocache
session.cookie_domain	no value	no value
session.cookie_httponly	Off	Off
session.cookie_lifetime	0	0
session.cookie_path	/	/
session.cookie_secure	Off	Off
session.entropy_file	no value	no value
session.entropy_length	0	0
session.gc_divisor	1000	1000
session.gc_maxlifetime	1440	1440
session.gc_probability	1	1
session.hash_bits_per_character	5	5
session.hash_function	0	0
session.lazy_write	On	On
session.name	PHPSESSID	PHPSESSID
session.referer_check	no value	no value
session.save_handler	files	files
session.save_path	no value	no value
session.serialize_handler	php	php
session.upload_progress.cleanup	On	On
session.upload_progress.enabled	On	On
session.upload_progress.freq	1%	1%
session.upload_progress.min_freq	1	1
session.upload_progress.name	PHP_SESSION_UPLOAD_PROGRESS	PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix	upload_progress_	upload_progress_
session.use_cookies	On	On
session.use_only_cookies	On	On
session.use_strict_mode	Off	Off
session.use_trans_sid	0	0

I dont have any assignment of $_SESSION to another variable like in bug 70013.

The application has been ported from php4. I have not added any new functionality concerning session management. For my poor experience with PHP session mgmt it seems to be a straight forward, simple implementation. 

Thank you for your efforts, hope to help other people as well
 [2015-09-29 07:06 UTC] buschmann at nidsa dot net
Sorry, in my previous comment i meant poor knowledge or understanding ("experience" stems from wrong formal german translation ...)

Thanks
 [2015-10-27 20:10 UTC] fabian at tag1consulting dot com
Very out of the blue guess:

I think you need to call session_save() before that will work properly, else the GC will garbage collect the session after a while.

Try setting session.gc_maxlifetime = 0 for a while to see if turning off the GC fixes the problem.

You could still create your own GC for the PG database, so turning GC off should be not a big problem compared to loss of data.
 [2015-11-11 01:56 UTC] t dot 1115 at ar54 dot com dot ar
I'm facing a similar problem but in my case I've narrowed down where it occurs. It appears that the problem is concurrently calling session_start() from 2 different requests. 

In theory one should block waiting for the other to finish. On any combination of operating systems and previous versions of PHP it used to work fine, but I'm finding that on recent versions of PHP combined with recent versions of Windows (in my case PHP 5.6.14 on Windows 10), instead of blocking, it returns a new empty session. 

I have a small test case involving 2 scripts. Basically: a.php creates a session and stores a variable in it. Then, it asynchronously calls b.php 200 times. b.php only checks if the variable is set. If it is not set, it returns http error code 500. 

Once executed, we should see 200 log entries returning http error code 200 (OK) but, instead, you'll see sporadic codes 500 (ERROR). Same script on other operating systems run fine. 

a.php
======================================

<?php
ini_set('default_charset','UTF-8');
mb_internal_encoding('UTF-8');
session_start(); 
$_SESSION['age'] = 41;

echo "Session set. My age is " . $_SESSION['age'];

?>
<!DOCTYPE HTML>
<html>
<head>
    <script src="https://code.jquery.com/jquery-1.9.1.min.js"></script>
    
    <script>

    for (i = 0 ; i < 200 ; i++)
    {
    	$.ajax({
            type: "GET",
            url: 'b.php'		
          });		        
    }

    </script>
     
</head>
<body>
</body>
</html>


b.php
======================================

<?php
ini_set('default_charset','UTF-8');
mb_internal_encoding('UTF-8');
session_start(); 

if ( isset($_SESSION['age']) && $_SESSION['age'] == 41)  {
    echo "OK"; 
} else {
    http_response_code(500);
    echo "ERROR";
}
 [2015-12-09 21:07 UTC] cdutary at grupocti dot com
I am facing a similar problem here. My problem ocurrs ONLY when pg_ AND unicode are involved:

class custom_session_handler implements SessionHandlerInterface {

    ...  //this class is storing session info into a PostgreSQL server. Server A.
}

Init our handler along with our session:

$handler = new custom_session_handler();
session_set_save_handler($handler, true);
session_name('my_session');
session_start();
And save some data into our session:

    $_SESSION['test'] = 'áéíóúñ';
At this point you can var_dump() your session all that you want and it will work, you can refresh the page and it will maintain session info for eternity but stay with me on this...

I need to check the fridge:

$seccond_server = pg_connect("host=#### port=#### dbname=#### user=#### password=######### or die("No bueno on db #2");
    print_r($_SESSION);

Session data seems ok on that print_r but when the script finishes your session will be broken;

Reload the page and you will get: PHP Warning:  session_start(): Failed to decode session object. Session has been destroyed in some location at some line

I posted the full code at Stack Overflow: http://stackoverflow.com/questions/34185536/php7-is-breaking-my-sessions-when-custom-session-handler-is-used-and-a-seccond-p
 [2015-12-29 00:30 UTC] yohgaki@php.net
-Status: Assigned +Status: Analyzed
 [2017-10-24 03:06 UTC] kalle@php.net
-Status: Analyzed +Status: Assigned
 [2019-02-01 14:42 UTC] cmb@php.net
> It seems to occur randomly, our suspicion goes to garbage
> collector or similar.

Not unlikely given your session.gc_* and session.use_strict_mode
settings.  If users are inactive for more than 24 minutes, their
session may be garbage collected, but the session cookie may have
not been expired, and since strict_mode is disabled, they'll get a
new session with the same session ID.
 [2019-02-13 06:19 UTC] yohgaki@php.net
-Status: Assigned +Status: Feedback
 [2019-02-13 06:19 UTC] yohgaki@php.net
This should be user defined save handler bug because user uses PostgreSQL as session data storage. 

I don't mind to take a look at the handler. Is it available?
 [2019-02-24 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2023-09-09 07:32 UTC] andy dot hilbig at clubsys dot co dot uk
Manu years ago I experienced Apache locking every few days, sometimes hours. My webpages call PHP which in turn EXEC to a VB program to prepare the HTML code. 

The answer ??. close the session, do the exec, restart the session on return

session_write_close();
exec('"' . $ExeDirPath . $ExeFilename . '.exe" ' . $interfaceFileName);
session_start ();

This has since NEVER failed in the 100's of millions of transactions
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Oct 12 03:01:28 2024 UTC