ID: 49867
Comment by: tomas dot plesek at gmail dot com
Reported By: nicolas dot lepage at yahoo dot fr
Status: Feedback
Bug Type: SPL related
Operating System: *
PHP Version: 5.3.0
New Comment:
Ok, I will provide test suite some time later in the evening, as this
issue is not easily demonstrated.
Previous Comments:
------------------------------------------------------------------------
[2010-02-11 10:58:35] 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 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..
------------------------------------------------------------------------
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