Zend Framework

Zend_Session error handler handles anything in E_ALL as an exception

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.5.1, 1.7.1
  • Fix Version/s: 1.9.0
  • Component/s: Zend_Session
  • Labels:
    None
  • Fix Version Priority:
    Should Have

Description

This is related to to http://framework.zend.com/issues/browse/ZF-1325

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); session_write_close(); restore_error_handler(); 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.

Issue Links

This issue is related to:
ZF-1325 "Unwritable session.save_path" when using defaults in Zend_Session and php.ini Minor Resolved
This issue is related to:
ZF-2900 Issue on Zend_Validate_Hostname Blocker Resolved

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Taylor Barstow added a comment -

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

Show
Taylor Barstow added a comment - The fix to ZF-1325 is the source of this issue.
Hide
Permalink
Ralph Schindler added a comment -

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.

Show
Ralph Schindler added a comment - 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.
Hide
Permalink
Florian Hoenig added a comment -

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?

Show
Florian Hoenig added a comment - 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?
Hide
Permalink
Simon R Jones added a comment -

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:

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) {
    	    	return;
    	}
        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

Show
Simon R Jones added a comment - 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: 
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) {
    	    	return;
    	}
        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
Hide
Permalink
Ralph Schindler added a comment -

Will reevaluate within 2 weeks.

Show
Ralph Schindler added a comment - Will reevaluate within 2 weeks.
Hide
Permalink
Matthew Ratzloff added a comment -

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

Show
Matthew Ratzloff added a comment - WHAT THE F^H^H^H^H^H^H^H^H^H^HI would really appreciate it if this were fixed.
Hide
Permalink
Matthew Ratzloff added a comment -

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

Show
Matthew Ratzloff added a comment - 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
Hide
Permalink
Matthew Ratzloff added a comment -

(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.

Show
Matthew Ratzloff added a comment - (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.
Hide
Permalink
Chad Cunningham added a comment -

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.

Show
Chad Cunningham added a comment - 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.
Hide
Permalink
Ralph Schindler added a comment -

Resolved in r15640

Show
Ralph Schindler added a comment - Resolved in r15640

People

Vote (6)
Watch (6)

Dates

  • Due:
    Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
2h
Original Estimate - 2 hours
Remaining:
2h
Remaining Estimate - 2 hours
Logged:
Not Specified
Time Spent - Not Specified
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Zend Framework. Try JIRA - bug tracking software for your team.