php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32330 session_destroy, "Failed to initialize storage module", custom session handler
Submitted: 2005-03-16 09:29 UTC Modified: 2010-07-16 12:08 UTC
Votes:186
Avg. Score:4.6 ± 0.7
Reproduced:155 of 164 (94.5%)
Same Version:65 (41.9%)
Same OS:77 (49.7%)
From: mfischer@php.net Assigned: mfischer (profile)
Status: Closed Package: Session related
PHP Version: 6CVS, 5CVS, 5.2.5, 4CVS (2005-03-17) OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mfischer@php.net
New email:
PHP Version: OS:

 

 [2005-03-16 09:29 UTC] mfischer@php.net
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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-17 10:14 UTC] mfischer@php.net
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-17 10:37 UTC] sniper@php.net
I see that the php_session_destroy() is called in php_session_decode() too..

 [2005-03-31 16:37 UTC] 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-05-21 19:19 UTC] rasmus@php.net
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-06-04 00:25 UTC] sniper@php.net
PS(mod_data) gets set to NULL with these:

session_write_close(),
session_module_name('foo'),
session_destroy()




 [2006-01-16 16:41 UTC] ajithts at gmail dot com
Hi folks,

I have also had the same problem. My /tmp was not a separate partition and it had full permissions.

I have then changed session.save_handler to "files" in php.ini. Initially it was "user". Everything worked perfectly after I have restarted httpd saving the changes.

Thanks and regards,
Ajith
 [2006-06-07 04:26 UTC] sean at oteams dot com
I struggled for several days with the "Failed to initialize storage module: user" problem.  I read everything I could find on php.net and in this bug database.  Finally, what solved the problem for me was this:

Whenever I made a call in my code to session_start(), I used an include statement to include the following from an include file:

<?php
ini_set("session.save_handler", "files");
session_start();
?>

And that did it.
 [2006-12-14 17:24 UTC] faithfulsoft at tiscali dot it
I've experienced this problem today, and it was driving me crazy.
I was able to resolve it thanks to the last post on this page.
I've put this two lines of code

ini_set("session.save_handler", "files");
session_start();

in a separate file, and I include them where I need.

The strange thing is that I borrowed the piece of code I am using from a GPL portal system, which is working like a charm on my local server with this line

ini_set('session.save_handler', 'files');

This is really strange.

Anyhow, thank you all guys.
 [2007-03-08 05:07 UTC] colossuswv at hotmail dot com
The ini_set workaround doesn't seem to work when using a db to store sessions. Using session_set_save_handler() again after session destroy does work however, albeit an undesirable solution.
 [2007-07-05 13:23 UTC] facingratio at email dot it
I confirm that the ini_set workaround doesn't work. The only solution i found is to use the session_set_save_handler(...) again after you call session_destroy(). Also session_write_close() followed by session_start() seems to generate the same fatal error.
 [2007-08-23 05:25 UTC] jkloske at itee dot uq dot edu dot au
I'm confirming that I'm also affected by this on all OSs and all versions of PHP I've tried it with (4/5, win/linux)

I'm calling session_write_close() not session_destroy() and it's still causing the same error. Re-calling session_set_save_handler between previous close and subsequent open does nothing; the error still occurs.

This means that phpMyAdmin (which uses multiple sessions for various authentication handlers at least) is not compatible with user session handlers, due to this bug :)
 [2008-01-22 05:43 UTC] gwynne@php.net
This bug still exists in PHP 5.2.5 release and current (as of this comment) PHP 6CVS. Using a fresh call to session_set_save_handler() does work, but as previously noted by others, this isn't a desirable behavior.
 [2008-02-23 06:43 UTC] fxmulder at gmail dot com
The problem is both mod_data getting set to NULL and zval_ptr_dtor(&mdata->names[i]); for each of the functions in ext/session/mod_user.c:PS_CLOSE_FUNC.  If the deconstructor calls are removed as well as the NULL replacements and efree() call on mdata then it works, except then the containing classes are never deconstructed.  This could possibly be moved to a location when the script is exiting, and/or another call to session_set_save_handler is made.
 [2008-03-07 23:21 UTC] gwynne@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2008-07-02 10:11 UTC] jani@php.net
Note: This fix will be in PHP 5.3 and upwards.
 [2010-07-15 21:00 UTC] dave at redterror dot net
Any chance the fix could be backported to 5.2, or I can get a reference to the fix that was applied?  I didn't see this bug number in the changelog.

I am still seeing the problem on 5.2.12, which was released almost 2 years after the fix was reported to have gone in.
 [2010-07-16 10:56 UTC] mfischer@php.net
-Assigned To: +Assigned To: mfischer
 [2010-07-16 10:56 UTC] mfischer@php.net
It's painful to find such old revisions in SVN, I know.

I cloned the git mirror from http://github.com/php/php-src/ and searched for the bug id and found it at http://github.com/php/php-src/commit/0b6c36990600898768861ac83c5809ce89912b62 .

You can get it as diff with http://github.com/php/php-src/commit/0b6c36990600898768861ac83c5809ce89912b62.diff

HTH
 [2010-07-16 12:08 UTC] johannes@php.net
This patch breaks binary compatibility and can't be added to stable branches. (Not to mention the fact that 5.2 support is going over to "security fixes only" after 5.2.14 where the final RC was released)

Feel free to apply the patches on on risk on your version. We can't support it.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 09 20:01:28 2024 UTC