Edit report at https://bugs.php.net/bug.php?id=70584&edit=1
ID: 70584
Updated by: php-bugs@lists.php.net
Reported by: buschmann at nidsa dot net
Summary: Spontanous loss of all $_SESSION variables
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Session related
Operating System: Windows
PHP Version: 7.0.0RC3
Assigned To: yohgaki
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2019-02-13 06:19:17] 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-01 14:42:14] 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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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