ID: 49867 Updated by: paj...@php.net Reported By: nicolas dot lepage at yahoo dot fr -Status: Open +Status: Feedback Bug Type: SPL related Operating System: * PHP Version: 5.3.0 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2010-02-11 10:41:12] nicolas dot lepage at yahoo dot fr Reopening ------------------------------------------------------------------------ [2010-02-11 10:36:31] 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-04 16:16:11] tomas dot plesek at gmail dot com This bug occured again on version 5.3.1 from dotdeb.org ------------------------------------------------------------------------ [2010-01-08 13:32:05] 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-01-04 12:59:32] 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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49867 -- Edit this bug report at http://bugs.php.net/?id=49867&edit=1
