Re: [PHP-DEV] Execution point of session save handler on shutdown
Hi, >> I have been investigating a problem occuring when using APC in >> combination with userspace session save handlers. This has been reported >> multiple times both in the APC and PHP bugtrackers, bugs related to this >> issue include (but are most likely not limited to): > > This has been documented feature for several years. > You should explicitly call session_write_close() when your custom > session handler is a userspace object. I would consider this a work-around to a design issue - but not a solution. With other extensions, I could imagine even crashing PHP in this way if a suitable extension is loaded - assume such an extension has some global state initialized on RINIT and deinitialized on RSHUTDOWN, and then after de-initialization the user-space session handler kicks in and tries to do something with the extension - all kinds of weird things could happen. If you say: ok, we want to force the user to use session_write_close(), then we should make sure php_session_flush() is only called at the end of the script if no userspace handler is installed, else emit a warning or whatever (if that's even possible at that point because output was already flushed completely). But even then you still have the problem with serialization. If you put an object into your $_SESSION data that has a __sleep function - and that __sleep function uses some kind of other functionality other than returning a simple array, you will run into problems. And that is the case regardless of whether you use a userspace session handler. I don't think that ANY extension should use the engine to execute userspace code in RSHUTDOWN - at all. If an extension does such a thing, I'd consider the resulting behaviour undefined and prone to all sorts of trouble. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Execution point of session save handler on shutdown
Hi, > I've used APC + custom session handler for ages without any problems. Probably just under different circumstances. > And couldn't this be fixed without such nasty hooks..? I'm open for other suggestions... Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Execution point of session save handler on shutdown
On Fri, Feb 19, 2010 at 16:54, Christian Seiler wrote: > Hello, > > [CC to pecl-dev since this is APC-related.] > > I have been investigating a problem occuring when using APC in > combination with userspace session save handlers. This has been reported > multiple times both in the APC and PHP bugtrackers, bugs related to this > issue include (but are most likely not limited to): This has been documented feature for several years. You should explicitly call session_write_close() when your custom session handler is a userspace object. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Execution point of session save handler on shutdown
I've used APC + custom session handler for ages without any problems. And couldn't this be fixed without such nasty hooks..? --Jani On 02/19/2010 05:54 PM, Christian Seiler wrote: Hello, [CC to pecl-dev since this is APC-related.] I have been investigating a problem occuring when using APC in combination with userspace session save handlers. This has been reported multiple times both in the APC and PHP bugtrackers, bugs related to this issue include (but are most likely not limited to): http://bugs.php.net/bug.php?id=48787 http://bugs.php.net/bug.php?id=48686 http://pecl.php.net/bugs/bug.php?id=16721 http://pecl.php.net/bugs/bug.php?id=16745 Using a debugger I have found the source of the problem. In my eyes, this is a design problem in PHP's session extension. Rationale: Currently, the session module calls php_session_flush() in its RSHUTDOWN function. This makes sure that the session handler is always called at the very end of execution. However, APC uses its RSHUTDOWN function to remove all class entries from the class table, since they are only shallow copies of memory structures of its cache and the Zend engine should not destroy the class entries by itself. The problem now occurs when the session save handler uses non-internal classes in some way. Since APC, as a dynamic extension, is always loaded AFTER the session module (always a static extension), and the module de-initialization is in reverse order, APC will unload all internal classes *before* the session save handler is executed. So when it is finally the turn of the the session save handler, the classes will no longer be present in the class table, causing the problems described above. Note that APC is not the only extension for which there is a problem with regards to de-initialization. The Spidermonkey extension destroys the current Javascript execution context in the RSHUTDOWN function, so if should any save handler use the Spidermonkey extension, it will not work. In theory, even the date extension could cause minor problems (since the default timezone is reset in RSHUTDOWN), but it gets away since it is always loaded *before* session and thus de-inititialized afterwards. I consider this to be a design problem in PHP's session extension. It tries to use the PHP engine to execute PHP code (the custom session save handler, possibly also the serialization handlers of objects etc.) during a phase where at least some other extension that may be used in that code are already de-initialized. The only reason why it got unnoticed so long is that the RSHUTDOWN code of most - but not all - extensions doesn't really have any really nasty side-effects on its use. It would not surprise me at all, however, if there were memory leaks and other strange this occurring due to this problem. My immediate fix for this problem is to make php_request_shutdown() execute the session save handler just after the userspace shutdown functions but before the RSHUTDOWN functions of the other modules. I have attached short patches to this mail for PHP 5.2, 5.3 and 6.0 that accomplish this. It's not very elegant but it is the least-invasive fix I could come up with. Not existing tests are broken in either of the three branches. Unfortunately, I was not able to create a unit test for this using core PHP alone, since all of the core extensions hide the problem. I wanted to get some feedback first. If nobody objects, however, I'll apply these patches to PHP 5.3 and PHP 6 tomorrow. As for PHP 5.2: I was extremely busy the last two months so I didn't really follow the list. Is it okay if I apply it? I do think this patch should go into the last release of PHP 5.2 (which will be used by quite a few people for a while) since this bug prevents people from using a custom session save handler in combination with APC. On a side note: For PHP6 we may think of adding an additional hook for modules that is executed at the very beginning of the shutdown phase for precisely this purpose. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Execution point of session save handler on shutdown
Hello,
[CC to pecl-dev since this is APC-related.]
I have been investigating a problem occuring when using APC in
combination with userspace session save handlers. This has been reported
multiple times both in the APC and PHP bugtrackers, bugs related to this
issue include (but are most likely not limited to):
http://bugs.php.net/bug.php?id=48787
http://bugs.php.net/bug.php?id=48686
http://pecl.php.net/bugs/bug.php?id=16721
http://pecl.php.net/bugs/bug.php?id=16745
Using a debugger I have found the source of the problem. In my eyes,
this is a design problem in PHP's session extension. Rationale:
Currently, the session module calls php_session_flush() in its RSHUTDOWN
function. This makes sure that the session handler is always called at
the very end of execution.
However, APC uses its RSHUTDOWN function to remove all class entries
from the class table, since they are only shallow copies of memory
structures of its cache and the Zend engine should not destroy the class
entries by itself.
The problem now occurs when the session save handler uses non-internal
classes in some way. Since APC, as a dynamic extension, is always loaded
AFTER the session module (always a static extension), and the module
de-initialization is in reverse order, APC will unload all internal
classes *before* the session save handler is executed. So when it is
finally the turn of the the session save handler, the classes will no
longer be present in the class table, causing the problems described above.
Note that APC is not the only extension for which there is a problem
with regards to de-initialization. The Spidermonkey extension destroys
the current Javascript execution context in the RSHUTDOWN function, so
if should any save handler use the Spidermonkey extension, it will not
work. In theory, even the date extension could cause minor problems
(since the default timezone is reset in RSHUTDOWN), but it gets away
since it is always loaded *before* session and thus de-inititialized
afterwards.
I consider this to be a design problem in PHP's session extension. It
tries to use the PHP engine to execute PHP code (the custom session save
handler, possibly also the serialization handlers of objects etc.)
during a phase where at least some other extension that may be used in
that code are already de-initialized. The only reason why it got
unnoticed so long is that the RSHUTDOWN code of most - but not all -
extensions doesn't really have any really nasty side-effects on its use.
It would not surprise me at all, however, if there were memory leaks and
other strange this occurring due to this problem.
My immediate fix for this problem is to make php_request_shutdown()
execute the session save handler just after the userspace shutdown
functions but before the RSHUTDOWN functions of the other modules. I
have attached short patches to this mail for PHP 5.2, 5.3 and 6.0 that
accomplish this. It's not very elegant but it is the least-invasive fix
I could come up with. Not existing tests are broken in either of the
three branches. Unfortunately, I was not able to create a unit test for
this using core PHP alone, since all of the core extensions hide the
problem.
I wanted to get some feedback first. If nobody objects, however, I'll
apply these patches to PHP 5.3 and PHP 6 tomorrow.
As for PHP 5.2: I was extremely busy the last two months so I didn't
really follow the list. Is it okay if I apply it? I do think this patch
should go into the last release of PHP 5.2 (which will be used by quite
a few people for a while) since this bug prevents people from using a
custom session save handler in combination with APC.
On a side note: For PHP6 we may think of adding an additional hook for
modules that is executed at the very beginning of the shutdown phase for
precisely this purpose.
Regards,
Christian
Index: ext/session/session.c
===
--- ext/session/session.c (revision 295251)
+++ ext/session/session.c (working copy)
@@ -36,6 +36,7 @@
#include "php_ini.h"
#include "SAPI.h"
+#include "php_main.h"
#include "php_session.h"
#include "ext/standard/md5.h"
#include "ext/standard/sha1.h"
@@ -2012,7 +2013,9 @@ static PHP_RINIT_FUNCTION(session) /* {{{ */
static PHP_RSHUTDOWN_FUNCTION(session) /* {{{ */
{
- php_session_flush(TSRMLS_C);
+ /* do not flush session, the flush method is assigned to
+ php_session_pre_shutdown_function in the MINIT, so it will be called
+ BEFORE execution has ended! */
php_rshutdown_session_globals(TSRMLS_C);
return SUCCESS;
@@ -2044,6 +2047,10 @@ static PHP_MINIT_FUNCTION(session) /* {{{ */
#ifdef HAVE_LIBMM
PHP_MINIT(ps_mm) (INIT_FUNC_ARGS_PASSTHRU);
#endif
+
+ /* Flush the session just before shutdown. */
+ php_session_pre_shutdown_function = php_session_flush;
+
return SUCCESS;
}
/* }}} */
@@ -2059,6 +2066,8 @@ static PHP_MSHUTDOWN_FUNCTION(session) /* {{{ */
Re: [PHP-DEV] Closures and $this: Please vote!
Hi, >> My suggestion is to wait until the 15th of January (that's one month >> since I started this thread) and that should have been enough time of >> everybody. > > So, it's 18th - are we moving forward with this? Yes, Sorry, I've been extremely busy for the last two months, I'll get back to this in the next few days. Since my last posting in mid-December nobody else commented on this. My overview back then still holds. The majority of people (internals@ and otherwise) was in favor of (A+), so I'll implement that and put details of the implementation and the discussion into the Wiki. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
