ID: 32330 Comment by: scliburn at trtinfo dot com Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Session related Operating System: * PHP Version: 4CVS, 5CVS (2005-03-17) Assigned To: sniper New Comment:
I would like to also add that I'm running and experiencing this issue in both api versions CGI/ISAPI. not sure if that mattered Previous Comments: ------------------------------------------------------------------------ [2005-03-23 20:34:44] scott at trtinfo dot com i am getting this error on the following environments: Windows2003 - Zend 2.03, php Version 5.0.3 Redhat 9, Zend 2.03, php Version 4.3.10 Redhat 9, Zend 2.03, php Version 4.3.9 this is happening more often each day. Sessions handler set to files, session repository directory does not have any space issues. Chmod on tmp dir set 777. I am however creating my own hash value for the session id. This is also done on another server and it has not had this session error at all. Yet. ------------------------------------------------------------------------ [2005-03-19 00:55:18] [EMAIL PROTECTED] Good catch, thanks. ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2005-03-16 09:29:18] [EMAIL PROTECTED] Description: ------------ When I use custom session handling functions and use the following session functions in this order: [...] session_set_save_handler(...) [...] session_start() [...] session_destroy() [...] session_start() I get "Fatal error: session_start(): Failed to initialize storage module: user (path: /var/lib/php4) in test.php on line 9" After session_destroy is called, the functions assigned with session_set_save_handler() do not work anymore and have to be assigned again. By calling session_set_save_handler() again after session_destroy() it will work. This applies to 4.9.10 and 5.0.3 as well. I think the cause is in session.c in php_session_destroy: [...] if (PS(mod)->s_destroy(&PS(mod_data), PS(id) TSRMLS_CC) == FAILURE) { retval = FAILURE; php_error_docref(NULL TSRMLS_CC, E_WARNING, "Session object destruction failed"); } php_rshutdown_session_globals(TSRMLS_C); php_rinit_session_globals(TSRMLS_C); [...] First, the user defined destroy-handler is called then php_rshutdown_session_globals and then php_rinit_session_globals. In php_rinit_session_globals PS(mod_data) is cleared static void php_rinit_session_globals(TSRMLS_D) { PS(id) = NULL; PS(session_status) = php_session_none; PS(mod_data) = NULL; PS(http_session_vars) = NULL; } which is a struct for the user defined functions. The current documentation says: "session_destroy() destroys all of the data associated with the current session." But it seems to do more: it also clears any custom set session save handlers which unexpected. Reproduce code: --------------- <?php function dummy() { } session_set_save_handler('dummy', 'dummy', 'dummy', 'dummy', 'dummy', 'dummy'); session_start(); session_destroy(); # comment in the next line and the test works #session_set_save_handler('dummy', 'dummy', 'dummy', 'dummy', 'dummy', 'dummy'); session_start(); ?> Expected result: ---------------- No fatal error message Actual result: -------------- Fatal error: session_start(): Failed to initialize storage module: user ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=32330&edit=1