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.

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

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.

Related RFC
https://wiki.php.net/rfc/precise_session_management

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.

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

Sorry, in my previous comment i meant poor knowledge or understanding ("experience" stems from wrong formal german translation ...)

Thanks

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.

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";
}

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

> 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.

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?

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.

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