Bug #70584 [Asn->Ana]: Spontanous loss of all $_SESSION variables

[email protected]
Newsgroups php.bugs
Message-ID <[email protected]>
Edit report at https://bugs.php.net/bug.php?id=70584&edit=1

 ID:                 70584
 Updated by:         [email protected]
 Reported by:        buschmann at nidsa dot net
 Summary:            Spontanous loss of all $_SESSION variables
-Status:             Assigned
+Status:             Analyzed
 Type:               Bug
 Package:            Session related
 Operating System:   Windows
 PHP Version:        7.0.0RC3
 Assigned To:        yohgaki
 Block user comment: N
 Private report:     N



Previous Comments:
------------------------------------------------------------------------
[2015-12-09 21:07:53] 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-11-11 01:56:43] 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-10-27 20:10:49] 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-09-29 07:06:11] 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-09-29 06:33:22] 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

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=70584


--
Edit this bug report at https://bugs.php.net/bug.php?id=70584&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.