|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data
Submitted: 2015-02-26 18:05 UTC Modified: 2021-09-28 14:29 UTC
Avg. Score:4.9 ± 0.3
Reproduced:13 of 14 (92.9%)
Same Version:12 (92.3%)
Same OS:1 (7.7%)
From: rbsimao at yahoo dot com dot br Assigned: yohgaki (profile)
Status: Assigned Package: Session related
PHP Version: Any OS: Any
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
26 + 17 = ?
Subscribe to this entry?

 [2015-02-26 18:05 UTC] rbsimao at yahoo dot com dot br
From manual page:

The piece of code below works ok most of the time. Randomly it does not work: session_regenerate_id(true) issues a warning saying it could not delete the old session data. But the session file is there and the permissions are untouched. Also, when it issues the warning, all the session data is lost on the new generated session.

Tested on ubuntu11 to ubuntu14 with default phps and windows 7/php5.5.

Test script:




Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-02-27 05:00 UTC]
-Status: Open +Status: Verified -Assigned To: +Assigned To: yohgaki
 [2015-02-27 05:00 UTC]
This is known issue and I proposed fix for this.
However, there are people who do not like my proposal.

Since session data and browser is not synced, session module must handle session_regenerate_id(true) in async way. This is what I proposed before.

I shall try to fix this again. Thank you for reporting.
 [2015-05-24 06:22 UTC]
This bug is related to
 [2015-09-07 22:17 UTC]
-Operating System: debian7, ubuntu11-12-13-14, win7 +Operating System: Any -PHP Version: 5.5.22 +PHP Version: Any
 [2015-09-19 23:41 UTC]
Procedure to reproduce this issue

echo "<pre>";


Start CLI server
$ php -S

Access test.php and press F5 few minutes

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.
 [2015-12-29 00:33 UTC]
-Status: Verified +Status: Analyzed
 [2016-01-13 19:06 UTC]
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.
 [2016-04-13 22:12 UTC] 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-04-13 22:14 UTC] 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:33 UTC] jolyon at nixbox dot com
My bad, apparently this is a known issue with a patch in the works for ZF1 - please disregard previous two comments.
 [2017-10-24 03:06 UTC]
-Status: Analyzed +Status: Assigned
 [2021-09-28 14:29 UTC]
This looks partially related to bug #78155.  We would need
separate lock files for each session to avoid the server side race
condition.  However, that would not solve the client side/network
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 16 18:01:30 2024 UTC