ZF-3020: Zend_Session error handler handles anything in E_ALL as an exception

Issue Type: Bug Created: 2008-04-02T08:37:24.000+0000 Last Updated: 2009-05-19T11:11:19.000+0000 Status: Resolved Fix version(s): - 1.9.0 (31/Jul/09)

Reporter: Taylor Barstow (tbarstow) Assignee: Ralph Schindler (ralph) Tags: - Zend_Session

Related issues: - ZF-1325



This is related to to

Take a look at how Zend_Session::start() handles errors that might arise during the real session_start() call:

set_error_handler(array('Zend_Session_Exception', 'handleSessionStartError'), E_ALL);

That error handler will unconditionally set a flag which gets picked up a few lines later (again in Zend_Session::start()):

    if (Zend_Session_Exception::$sessionStartError !== null) {
       set_error_handler(array('Zend_Session_Exception', 'handleSilentWriteClose'), E_ALL);
       throw new Zend_Session_Exception(__CLASS__ . '::' . __FUNCTION__ . '() - ' . Zend_Session_Exception::$sessionStartError);

So, ANYTHING falling under E_ALL (even E_WARNING or, gasp!, E_NOTICE) will end up raising an exception, and the session will not start. Surely this is not the desired behavior.

In my particular situation, this is a problem because I get a couple of normal/expected include warnings thrown by Zend_Loader during my unserialize callback.


Posted by Taylor Barstow (tbarstow) on 2008-04-02T08:38:45.000+0000

The fix to ZF-1325 is the source of this issue.

Posted by Ralph Schindler (ralph) on 2008-04-22T10:45:14.000+0000

This is actually the intended behavior.

In fact, Zend_Loader shouldnt be throwing warnings or errors, and there is a new verison in the incubator that supresses those issues.

I'm gonna wait on this.


Updating project management info.

Posted by Florian Hoenig (flo) on 2008-06-10T13:53:40.000+0000

I found the same problem. Have a custom savehandler, which uses Zend_XmlRpc_Client. This somewhere down the chain uses Zend_Validate_Hostname and for a .com address it tried to do Zend_Loader::isReadible("Zend/Validate/Hostname/Com.php"), which does not exist. isReadible tried to @fopen and surpress the warning when it does NOT exist. Which is fine, except the above error handler seems to ignore the "@" in front of the fread.

This renders Zend_XmlRpc_Client unusable within a session savehandler callback !!

ZF 1.5.2 that is. and php 5.2.1 through php 5.2.6 is what I tried. I when through all possible php.ini settings, but could not figure out how to make Zend_Session::start() respect the @ in Zend_Loader.

Any glue?

Posted by Simon R Jones (studio24) on 2008-11-02T07:17:34.000+0000

I've been looking into ZF-2900 which is related.

The underlying problem is that if a custom error handler is used then this will always receive errors, even when they are suppressed. The solution is to update the code in Zend_Session_Exception::handleSessionStartError as so:

<pre class="highlight">
static public function handleSessionStartError($errno, $errstr, $errfile, $errline, $errcontext)
        // Do not throw an exception if this is a suppressed error - see ZF-3020
        if (error_reporting() === 0) {
        self::$sessionStartError = $errfile . '(Line:' . $errline . '): Error #' . $errno . ' ' . $errstr . ' ' . $errcontext;

I can make this change myself if given SVN commit rights to the Zend/Session folder

best wishes, Simon

Posted by Ralph Schindler (ralph) on 2009-01-10T09:34:07.000+0000

Will reevaluate within 2 weeks.

Posted by Matthew Ratzloff (mratzloff) on 2009-01-10T14:05:59.000+0000

WHAT THE F^H^H^H^H^H^H^H^H^H^HI would really appreciate it if this were fixed.

Posted by Matthew Ratzloff (mratzloff) on 2009-01-10T14:12:22.000+0000

To add more information to my previous outburst,

Warning: array_key_exists() [function.array-key-exists]: The first argument should be either a string or an integer in /usr/lib64/php/ZendFramework-1.7.1/library/Zend/Filter/Input.php on line 429

Fatal error: Exception thrown without a stack frame in Unknown on line 0

Disappears when Zend_Session::start() is commented out.

Thanks Ralph

Posted by Matthew Ratzloff (mratzloff) on 2009-01-10T14:46:24.000+0000

(sigh) Sorry, everyone. It turns out it was my own dumb fault. There was a bug in our custom save handler. After two hours trying to debug this, my eyes were going cross-eyed. My apologies.

Posted by Chad Cunningham (gnarfle) on 2009-04-09T13:50:04.000+0000

So is the 1.8 suppress warnings going to fix this? And is there any chance of it being fixed in the 1.7 branch? I've hacked ZendSession to get around this which I hate doing, but this bug is a royal pain.

I'm using Doctrine with ZF, and doctrine does a lot of on the fly class generation. Zend autoloader tries to load these classes when it doesn't need to, however I can easily suppress these warnings by setting error reporting and the app works great. That is, until I try to save a Doctrine object in the session. Since Zend Session believes that I don't know what I want my error reporting to be and throws an exception for every little warning or notice, it will grind the app to a halt for a problem that I've configured the app to ignore.

Posted by Ralph Schindler (ralph) on 2009-05-19T11:11:15.000+0000

Resolved in r15640

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.