php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49867 spl_autoload crashes when called in write function of custom sessionSaveHandler
Submitted: 2009-10-13 16:41 UTC Modified: 2010-11-02 19:43 UTC
Votes:18
Avg. Score:4.4 ± 0.8
Reproduced:17 of 17 (100.0%)
Same Version:8 (47.1%)
Same OS:10 (58.8%)
From: nicolas dot lepage at yahoo dot fr Assigned: felipe (profile)
Status: Closed Package: SPL related
PHP Version: 5.3.0 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: nicolas dot lepage at yahoo dot fr
New email:
PHP Version: OS:

 

 [2009-10-13 16:41 UTC] nicolas dot lepage at yahoo dot fr
Description:
------------
When trying to instantiate a class that is not defined within the write function that has been registered as a custom session save handler, the following problems occur :
_ functions that have been registered by spl_autoload_register are not called
_ a fatal error is generated by spl_autoload()

In the reproduce code, the normal behavior would be to generate a fatal error 'class not found'.

This problem occurs only in the write function and not in the others.

Additionnaly, when I replace the instantiation code by a call to spl_autoload_functions(), the apache server crashes.

It could be related to bug #37111.

Reproduce code:
---------------
<?php
function test_autoload($className) {
}

function open($save_path, $session_name) {
	return true;
}

function close() {
	return true;
}

function read($id) {
	return '';
}

function write($id, $sess_data) {
	new NotLoadedClass();
	return true;
}

function destroy($id) {
	return true;
}

function gc($maxlifetime) {
	return true;
}

spl_autoload_register('test_autoload');

session_set_save_handler("open", "close", "read", "write", "destroy", "gc");

session_start();
?>

Expected result:
----------------
Fatal error: Class 'NotLoadedClass' not found in F:\xampp\htdocs\test\test.php on line 18

Actual result:
--------------
Fatal error: spl_autoload() [<a href='function.spl-autoload'>function.spl-autoload</a>]: Class NotLoadedClass could not be loaded in F:\xampp\htdocs\test\test.php on line 18

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-30 17:17 UTC] tomas dot plesek at gmail dot com
I can confirm this bug for PHP version 5.2.10 on Linux.

In my case, the custom session handler code is a class, but the same behavior occurs. When a class is instantiated inside write method and that class should be loaded by an autoloader function, fatal error with already mentioned message is issued (like no autoloader methods are registered) and upon call to spl_autoload_functions(), Apache segfaults.
I used PHP 5.2.6 prior to upgrade and the code worked fine on that version.
 [2009-11-10 03:41 UTC] hevayo at gmail dot com
I also got this Error when I update from php 5.2.6 to php 5.2.10. 

But I found out it only comes up if you have php-apc module enabled. When you disable the apc module the error is not there
 [2009-11-12 20:16 UTC] daedalusvx at gmail dot com
I can confirm that this bug occurs on Ubuntu 9.10 with PHP 5.2.10, and does NOT occur on PHP 5.3.0 on OS X through MacPorts.  Both have APC installed and enabled.
 [2009-11-12 23:01 UTC] felipe@php.net
Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [2009-11-13 18:05 UTC] tomas dot plesek at gmail dot com
I can confirm that on stock version of 5.3.0, this bug does NOT occur.
 [2009-11-20 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-12-05 07:45 UTC] laruence at yahoo dot com dot cn
I can confirm this bug for PHP version 5.2.11 with apc enabled , and I 
found why:

because the request shutdown function of apc is called before the 
session moudule request shutdown function be called.

in which(apc shutdown function), will empty the EG(class_table), 
(apc_main.c apc_deactivate function), so when the request shutdown 
function of session was called , the class_table is empty, 

and why core dump when spl_autoload enabled is also simply , because 
when zif_spl_autoload was called , it use active_opline->op_code, 
while the active_opline is NULL then..

you can find more info in:http://www.laruence.com/2009/12/05/1172.html

sorry for my poor english
 [2010-01-04 12:59 UTC] rik dot meijer at moxio dot com
I can confirm that the submitted code to reproduce this problem also 
'works' on a server without PHP APC installed (used <?php 
var_dump(function_exists('apc_add')); ?> to check). PHP version 
5.2.12.

Are there any other extensions that could cause this behavior?

Loaded extensions:
date, libxml, openssl, pcre, zlib, bz2, calendar, ctype, hash, filter, 
ftp, gettext, gmp, session, iconv, pcntl, readline, Reflection, 
standard, shmop, SimpleXML, SPL, sockets, exif, tokenizer, xml, cgi-
fcgi, bcmath, curl, dba, dbase, dom, gd, htscanner, imap, json, ldap, 
mbstring, mcrypt, mhash, mysql, mysqli, pdf, PDO, pdo_mysql, 
pdo_pgsql, pdo_sqlite, pgsql, soap, wddx, xmlreader, xmlrpc, 
xmlwriter, xsl, zip, Zend Optimizer
 [2010-01-08 13:32 UTC] anonymous at mail dot com
I found out that by adding a 'session_write_close()' call at the end of my index.php, the problem seems to disappear.

I found this fix thanks to:

http://stackoverflow.com/questions/1364750/opcode-apc-xcache-zend-doctrine-and-autoloaders

and checked the source code of the Zend framework to find that the writeClose() function basically only does a 'session_write_close()' call.

Hope it helps..
 [2010-02-04 16:16 UTC] tomas dot plesek at gmail dot com
This bug occured again on version 5.3.1 from dotdeb.org
 [2010-02-11 10:36 UTC] tomas dot plesek at gmail dot com
I think more insight is welcome, so here we go:

As to the article on stackoverflow referenced above, it works, but in 
somewhat different context. The fact mentioned there work arounds the 
problem with Zend Framework and opcode cachers. It is true, that if 
you have no custom session handler ant you won't call either 
Zend_Session::writeClose() (or session_write_close() for that matter), 
it will crash yout sp_autoload in described manner. 

What are we dealing with here is when a custom handler is defined as a 
class and it tries to instantiate another class (say some wrapper 
object around the session data), the issue will occur in these 
situations: 
 * calling new on non-defined class altogether
 * calling new on a class that is to be autoloaded through autoloader
 * the class instatiated through new hasDEPENDENT CLASS(es) THAT USE 
AUTOLOADER for their function, i.e.: I can require_once the class 
giving me trouble, but if it depends on other classes, we are back to 
square one.

What is the most confusing fact, the autoloader complains about non-
loadable classes, but it can be a class half-way down the dependency 
tree. (and that is why I've seen this bug reported on Doctrine project 
bugtracker, because if you use Doctrine class for session saving like 
I do, the autoloader will probably complain about not able to load 
some Doctrine class) It is as if the autoloader crashes, but not 
immidiately in the write function of the session class.

As I mentioned before, 5.2.6 was working for me, so was 5.3.0 (but 
from Zend server CE version), the rest in between and the latest build 
(5.3.1) give me the trouble. 

I can supply more detail to developers, I studied this phenomenon 
rather thoroughly, as you can imagine.
 [2010-02-11 10:41 UTC] nicolas dot lepage at yahoo dot fr
Reopening
 [2010-02-11 10:58 UTC] pajoye@php.net
Can you please provid a small reproduce script, self contained, so we can run a diagnostic and try to fix this issue.

Please post this script here, this bug report seems to be valid but the infos are splitted between blog posts, external forums and extensive explanations, that does not help.
 [2010-02-11 13:55 UTC] tomas dot plesek at gmail dot com
Ok, I will provide test suite some time later in the evening, as this 
issue is not easily demonstrated.
 [2010-02-19 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2010-03-09 08:30 UTC] travisghansen at yahoo dot com
After many hours I finally found this bug report and I am experiencing this same 
issue.  With a little guidance (I don't claim to be an expert) I'd be happy to 
provide a self contained script.
 [2010-06-12 11:24 UTC] zapparov at member dot fsf dot org
Hello,

Have exactly the same problem with Zend Framework + Doctrine (they both register 
own autoloaders). So when APC is enabled - it reproduces same fatal error. I'll 
try to gather more information about what happens little bit later.

My PHP version is 5.3.2
 [2010-06-12 12:23 UTC] zapparov at member dot fsf dot org
Forgot to say - error occurs wonly when APC is enabled.
 [2010-06-12 15:48 UTC] rasmus@php.net
Doesn't calling session_write_close() completely solve this issue?
 [2010-06-12 23:34 UTC] zapparov at member dot fsf dot org
Unfortunately not for me.
Also, by some reason this problem occurs only on some requests. I'll try to 
prepare a simple test which will reproduce this issue soonly.
 [2010-06-12 23:39 UTC] zapparov at member dot fsf dot org
And one more interesting thing. This Fatal error is thrown (!) after all 
operations were completed - so Im receiving exactly what I was expecting to 
receive but with Fatal Error and it's trace appended to it. o_O
 [2010-08-12 19:44 UTC] iamcraigcampbell at gmail dot com
Just experienced this issue after upgrading to PHP 5.3.3, APC 3.1.4 on Debian 
GNU/Linux 4.0.

When using the session handler from an instance of a class it would give a fatal 
error: Fatal error: Undefined class constant...

After switching to use static session handler methods there was no longer a 
fatal error, but it caused a segfault which was traced back to 
spl_autoload_register().

Tried a bunch of stuff but was able to fix the issue by registering a shutdown 
function similar to this:

register_shutdown_function('shutdown');

function shutdown()
{
    session_write_close();
}
 [2010-11-02 19:43 UTC] felipe@php.net
-Status: No Feedback +Status: Closed -Assigned To: +Assigned To: felipe
 [2010-11-02 19:43 UTC] felipe@php.net
This bug has been fixed in SVN.

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.

This bug has been fixed by fixing bug #53141
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 05 16:01:30 2024 UTC