ID:               32330
 Comment by:       scott 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 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.


Previous Comments:
------------------------------------------------------------------------

[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

Reply via email to