ID: 32330
Comment by: ts at dreamcoder dot dk
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-03-17)
New Comment:
This bug is still very much causing problems.
Without knowing about the code side of it, this bug reminds me of the
php_value leak there was amoung virtualhosts in apache once - where the
value from one virtualhost was leaked in to another.
Manually adding ini_set('session.save_handler', 'files') to the top of
PHP files, solves the problem.
Previous Comments:
------------------------------------------------------------------------
[2005-06-04 00:25:54] [EMAIL PROTECTED]
PS(mod_data) gets set to NULL with these:
session_write_close(),
session_module_name('foo'),
session_destroy()
------------------------------------------------------------------------
[2005-05-21 19:19:42] [EMAIL PROTECTED]
I think you are on the right track mfischer. It looks like PS(mod) and
PS(mod_data) can get out of synch which would cause this. And I think
all the others with seemingly unrelated issues are actually related.
If PS(mod_data) leaks out of the per-request sandbox and infects
subsequent requests all it takes is one application on a server to use
its own session handler and it could affect other seemingly trivial
standalone session apps on that server.
------------------------------------------------------------------------
[2005-03-31 16:37:51] evenh+phpbug at pvv dot ntnu dot no
I experienced this one too, but only when using tavi.sourceforge.net.
This intrigued me, and I've developed a little script to give
information related to this issue.
The script at http://tavi.sourceforge.net/bug32330.php shows a counter
which jumps around at it own free will, seemingly. This due to the
changing host underneath, see changing $_SERVER['SERV_ADDR']. The
script always uses /tmp, and it's always writeable, but it's not on the
same computer!
This could be fixed by using a common path, as is done in
http://tavi.sourceforge.net/bug32330fix.php . And now the counter
works, and I don't get the "Failed to initialize..."-message either.
The reason for not getting the message, I've experienced, could be
related to accidentially calling session_start() twice... Either in the
same script, or script running in concurrent time space. Or maybe the
lack of session_write_close()?
Note that both the supplied script would include phpinfo() if adding
"?a" (or anything at all) after the script name. The scripts will be
available for some weeks. Feel free to copy them if needed... ;-)
But the messages seems to have gone away, so I'm happy. For now.
Regards,
Even Holen
------------------------------------------------------------------------
[2005-03-17 10:37:29] [EMAIL PROTECTED]
I see that the php_session_destroy() is called in php_session_decode()
too..
------------------------------------------------------------------------
[2005-03-17 10:14:08] [EMAIL PROTECTED]
I unfortunately lack the time to verify this with a new php
installation currently.
By looking at
http://cvs.php.net/co.php/php-src/ext/session/session.c?r=1.336.2.50
(latest commit of 4_3 branch) the relevant parts of the code haven't
changed. PS(mod_data) is still set to NULL in php_rinit_session_globals
which is called from php_session_destroy, this when a user from PHP
calls session_destroy(), the custom session save handlers are removed.
Thanks
------------------------------------------------------------------------
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
http://bugs.php.net/32330
--
Edit this bug report at http://bugs.php.net/?id=32330&edit=1
