Edit report at https://bugs.php.net/bug.php?id=69127&edit=1
ID: 69127
Comment by: jolyon at nixbox dot com
Reported by: rbsimao at yahoo dot com dot br
Summary: session_regenerate_id(true) randomly generates a
warning and loses session data
Status: Analyzed
Type: Bug
Package: Session related
Operating System: Any
PHP Version: Any
Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
My bad, apparently this is a known issue with a patch in the works for ZF1 - please disregard
previous two comments. https://github.com/zendframework/zf1/issues/659
Previous Comments:
------------------------------------------------------------------------
[2016-04-13 22:14:44] jolyon at nixbox dot com
I forgot to add our issue is PHP 7.0.x only, When we switch back to PHP 5.6.20,
session_regenerate_id works fine with our memcache backend. Also, turning off memcache backend
entirely resolves the issue. For now, we can just not use regenerateId, but would prefer to keep it
enabled for session security reasons.
------------------------------------------------------------------------
[2016-04-13 22:12:11] jolyon at nixbox dot com
Is this also related to alternate session handlers? session_regenerate_id is failing for us when we
add a custom save handler (memcache, in our case) and is returning the same error:
Recoverable Error(4096) session_regenerate_id(): Failed to create(read) session ID: user (path:
/var/lib/php/session) occurred at line 320 in /var/local/app/library/Zend/Session.php
We are using version 1.12.16 of Zend Framework. After troubleshooting their library code, I believe
this is a core PHP issue, not ZF.
I think this might be indirectly related, but if not I will create a new ticket with details.
------------------------------------------------------------------------
[2016-01-13 19:06:09] yohgaki@php.net
Session module code has race condition.
When session_regenerate_id(true) is called, session module close/unlock current session, then remove
it. If there is other access for the session, it waits until unlocked and accesses empty obsolete
data.
This situation can be avoided by RDBMS's serialized level transaction isolation, but file
system based storage cannot.
------------------------------------------------------------------------
[2015-09-29 02:07:14] yohgaki@php.net
Related RFC
https://wiki.php.net/rfc/precise_session_management
------------------------------------------------------------------------
[2015-09-19 23:41:17] yohgaki@php.net
Procedure to reproduce this issue
test.php
--------------
<?php
ob_start();
session_start();
echo "<pre>";
var_dump(session_id(),
$_SESSION['v']++);
session_regenerate_id(true);
var_dump(session_id());
?>
--------------
Start CLI server
$ php -S 127.0.0.1:8888
Access test.php and press F5 few minutes
http://127.0.0.1:8888/test.php
You'll see counter value ($_SESSION['v']) is resetted sometimes.
PHP 7.0 git + Fedora 22 + Chrome 45.0.2454.93 (64-bit) : Easy to reproduce. Thousands of requests
are enough.
PHP 7.0 git + Fedora 22 + Firefox 40.0.3 : Very hard to reproduce. Tens of thousands of requests are
required.
CLI server process requests one by one. The reason why there is difference would be how browser
locks cookie data. It seems Chrome locking is more lazy or no locks at all. (BTW, even if browser
locks cookie strictly, lost packet/etc could cause lost session. Therefore, "eventually
consistent" approach is required for reliable HTTP session management.)
Let me know if you(anyone) could reproduce the bug or not by this procedure - PHP version, OS
name/version, Browser name/version and easiness/hardness of reproducibility.
------------------------------------------------------------------------
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=69127
--
Edit this bug report at https://bugs.php.net/bug.php?id=69127&edit=1