5

I never had problems with any of my projects. Just recently when I ran a pacman-update in arch linux (which updated to 5.4) many of my projects where not runnable anymore.

Interestingly the problem only occurs as soon as the session-file was created on the filesystem. I mean, I can call the website a first time, as long as the /tmp/sess* does not exist.

When I want to call it a second time and /tmp/sess* has already been written, I get the following error (including stacktrace, Zend Framework).

Zend_Controller_Exception: session has already been started by session.auto-start or session_start()#0 /srv/http/bahasa/library/Zend/Session/Namespace.php(143): Zend_Session::start(true)
#1 /srv/http/bahasa/library/Zend/Auth/Storage/Session.php(87): Zend_Session_Namespace->__construct('Zend_Auth')
#2 /srv/http/bahasa/library/Zend/Auth.php(91): Zend_Auth_Storage_Session->__construct()
#3 /srv/http/bahasa/library/Zend/Auth.php(141): Zend_Auth->getStorage()
#4 /srv/http/bahasa/library/Skoch/Controller/Plugin/Navigation.php(59): Zend_Auth->hasIdentity()
#5 /srv/http/bahasa/library/Zend/Controller/Plugin/Broker.php(287): Skoch_Controller_Plugin_Navigation->dispatchLoopStartup(Object(Zend_Controller_Request_Http))
#6 /srv/http/bahasa/library/Zend/Controller/Front.php(928): Zend_Controller_Plugin_Broker->dispatchLoopStartup(Object(Zend_Controller_Request_Http))
#7 /srv/http/bahasa/library/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#8 /srv/http/bahasa/library/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#9 /srv/http/bahasa/public/index.php(30): Zend_Application->run()
#10 {main} in /srv/http/bahasa/library/Zend/Controller/Plugin/Broker.php on line 312

Of course I already checked other answers for this problem on stackoverflow, but:

  • session.auto-start is set to 0
  • there is no session_start() call at a place outside library/Zend/ (did grep -r on the whole project dir)
  • writing Zend_Session::start() in Bootstrap.php (as a bugfix) lead to new fatal errors
  • filesystem rights are ok, /tmp has 777 and the created sess-file has http rw (777 does not change the behaviour).

Also as said it strangely happened as soon as I updated from PHP 5.3 to PHP 5.4. The problem is, downgrading does not seem to work (then the mysql-libraries are broken somehow).

And as already mentioned, the most strange thing to me is, that it only happens when the session-file has been created in /tmp. When /tmp does not have a session file, it all works perfectly.

And yeah, it’s not only my own project affected, but also that I am working on for another company (which runs like charms on their server and their local PCs), so that also sort of contradicts the problem within my own code (as same thing happens at two Zend Framework projects).

And of course my project also runs like charms on my online webspace with PHP 5.2.12.

I guess the PHP notice before could also be interesting:

Notice: Array to string conversion in /srv/http/bahasa/library/Zend/Session/Exception.php on line 58

Call Stack:
0.0009     134352   1. {main}() /srv/http/bahasa/public/index.php:0
0.2805    3703732   2. Zend_Application->run() /srv/http/bahasa/public/index.php:30
0.2805    3703756   3. Zend_Application_Bootstrap_Bootstrap->run() /srv/http/bahasa/library/Zend/Application.php:366
0.2806    3703876   4. Zend_Controller_Front->dispatch() /srv/http/bahasa/library/Zend/Application/Bootstrap/Bootstrap.php:97
0.2873    3829732   5. Zend_Controller_Plugin_Broker->routeStartup() /srv/http/bahasa/library/Zend/Controller/Front.php:908
0.2873    3829820   6. Skoch_Controller_Plugin_Autologin->routeStartup() /srv/http/bahasa/library/Zend/Controller/Plugin/Broker.php:237
0.2883    3840992   7. Zend_Auth->hasIdentity() /srv/http/bahasa/library/Skoch/Controller/Plugin/Autologin.php:12
0.2884    3841016   8. Zend_Auth->getStorage() /srv/http/bahasa/library/Zend/Auth.php:141
0.2960    3980864   9. Zend_Auth_Storage_Session->__construct() /srv/http/bahasa/library/Zend/Auth.php:91
0.2960    3981072  10. Zend_Session_Namespace->__construct() /srv/http/bahasa/library/Zend/Auth/Storage/Session.php:87
0.2961    3981232  11. Zend_Session::start() /srv/http/bahasa/library/Zend/Session/Namespace.php:143
0.2968    3989956  12. session_start() /srv/http/bahasa/library/Zend/Session.php:469
0.2972    3997536  13. PropelAutoloader->autoload() /srv/http/bahasa/library/Zend/Session.php:0
0.3000    4060508  14. require('/srv/http/bahasa/application/models/bahasa/User.php') /srv/http/bahasa/library/propel-1.6.4/runtime/lib/util/PropelAutoloader.php:108
0.3377    4925056  15. Zend_Session_Exception::handleSessionStartError() /srv/http/bahasa/library/propel-1.6.4/runtime/lib/util/PropelAutoloader.php:16

However, Propel does not seem to have any session_start() within the own code, so that’s not the cause (propel also lies within the checked project director).

I personally do not see the full meaning in this notice yet, but the longer I look at it the more it seems to be related to the error (at least the stack trace, I mean the notice is only about array to string conversion).

Backtraces for calls to Zend_Session::start()

Okay, I found the backtraces when Zend_Session::start() gets called twice.

First:

#0  Zend_Session::start(1) called at [/srv/http/bahasa/library/Zend/Session/Namespace.php:143]
#1  Zend_Session_Namespace->__construct(Zend_Auth) called at [/srv/http/bahasa/library/Zend/Auth/Storage/Session.php:87]
#2  Zend_Auth_Storage_Session->__construct() called at [/srv/http/bahasa/library/Zend/Auth.php:91]
#3  Zend_Auth->getStorage() called at [/srv/http/bahasa/library/Zend/Auth.php:141]
#4  Zend_Auth->hasIdentity() called at [/srv/http/bahasa/library/Skoch/Controller/Plugin/Autologin.php:12]
#5  Skoch_Controller_Plugin_Autologin->routeStartup(Zend_Controller_Request_Http Object ([] => Array ([0] => _GET,[1] => _POST),[] => /de/,[] => ,[] => ,[] => ,[] => Array (),[] => ,[] => Array (),[] => ,[] => ,[] => module,[] => ,[] => controller,[] => ,[] => action)) called at [/srv/http/bahasa/library/Zend/Controller/Plugin/Broker.php:237]
#6  Zend_Controller_Plugin_Broker->routeStartup(Zend_Controller_Request_Http Object ([] => Array ([0] => _GET,[1] => _POST),[] => /de/,[] => ,[] => ,[] => ,[] => Array (),[] => ,[] => Array (),[] => ,[] => ,[] => module,[] => ,[] => controller,[] => ,[] => action)) called at [/srv/http/bahasa/library/Zend/Controller/Front.php:908]
#7  Zend_Controller_Front->dispatch() called at [/srv/http/bahasa/library/Zend/Application/Bootstrap/Bootstrap.php:97]
#8  Zend_Application_Bootstrap_Bootstrap->run() called at [/srv/http/bahasa/library/Zend/Application.php:366]
#9  Zend_Application->run() called at [/srv/http/bahasa/public/index.php:29]

Second:

#0  Zend_Session::start(1) called at [/srv/http/bahasa/library/Zend/Session/Namespace.php:143]
#1  Zend_Session_Namespace->__construct(Zend_Auth) called at [/srv/http/bahasa/library/Zend/Auth/Storage/Session.php:87]
#2  Zend_Auth_Storage_Session->__construct() called at [/srv/http/bahasa/library/Zend/Auth.php:91]
#3  Zend_Auth->getStorage() called at [/srv/http/bahasa/library/Zend/Auth.php:141]
#4  Zend_Auth->hasIdentity() called at [/srv/http/bahasa/library/Skoch/Controller/Plugin/Navigation.php:59]
#5  Skoch_Controller_Plugin_Navigation->dispatchLoopStartup(Zend_Controller_Request_Http Object ([] => Array ([0] => _GET,[1] => _POST),[] => /de/,[] => ,[] => ,[] => de,[] => …
hakre
  • 193,403
  • 52
  • 435
  • 836
aufziehvogel
  • 7,167
  • 5
  • 34
  • 56
  • make sure you checked `session.auto-start` at runtime, via ini_get() because looking at config files isn't a reliable way to see the final applied settings. – goat Jun 29 '12 at 16:52
  • Okay, checked that. `string(1) "0"` So that’s ok too. – aufziehvogel Jun 29 '12 at 16:55
  • bizarre. I think I would just grep for all session_start() calls, and insert a log statement where each is called. or use xdebug. – goat Jun 29 '12 at 17:01
  • Found the problem by tracing all calls to session down and check why `self::$_sessionStarted` was not set to true. But I do not know yet, why this behaviour has changed from PHP 5.3 to 5.4. The notice existed in PHP 5.3, too. – aufziehvogel Jun 29 '12 at 17:22

4 Answers4

10

Okay, I found the error. It’s totally nothing you would have been able to find out, but the general answer might be interesting for others.

General answer

The notice really had to do with the error. The problem is, Zend_Session_Exception gets registered as error handler for session_start() and session_start() passed the small notice on to Zend_Session_Exception. Even though it’s only a notice (which does not get fired on the production system, thus it worked there), Zend_Session_Exception gets fired and it sets Zend_Session_Exception::$sessionStartError to an error.

As soon as such an error gets logged, the session will not be registered to Zend_Session. Even if session_start() returns true itself

You can see this in this line ($startedCleanly indicates the return value of session_start()): if (!$startedCleanly || Zend_Session_Exception::$sessionStartError != null) {

Specific answer

In my special case, this all was due to a inheritance conflict. I did not add the parameters of Propels (database ORM) Base-classes to my subclasses. Then PHP sent a notice, that I should correct this.

Because such a Propel object lived within my session (User), the notice was fired exactly when session_start() was called. This is why Zend_Session_Exception was alerted. And then it went as described above.

Still open question

What I have not found out, is why this behaviour came up in PHP 5.4. I had not implemented the parameters before either, but it was never seen as a problem when resolving the session. Guess they have changed something in opening session-values.

aufziehvogel
  • 7,167
  • 5
  • 34
  • 56
  • to first fix the Array to String error, use this https://github.com/piwik/piwik/commit/f57171e8d638e859a28966ce1678ffb9934100c8 then in Zend_Session do a var_dump of line 483 to find out your notice error. – Clay Nov 09 '15 at 03:59
4

If you're getting Zend_Session_Exception after upgrading from PHP 5.3 to PHP 5.4+ the problem can be caused by E_STRICT errors. In PHP 5.4 E_STRICT became part of E_ALL.

You can disable strict errors in your php.ini:

error_reporting = E_ALL & ~E_STRICT

You would expect that the exception will be gone, but the problem is in the following lines in Zend_Session class:

$errorLevel = (is_int(self::$_throwStartupExceptions)) ? self::$_throwStartupExceptions : E_ALL;

// some code omitted
set_error_handler(array('Zend_Session_Exception', 'handleSessionStartError'), $errorLevel);

// some code omitted
set_error_handler(array('Zend_Session_Exception', 'handleSilentWriteClose'), $errorLevel);

Basically, Zend_Session_Exception is registered as an error handler and it will be called for all error levels (regardless to the settings of the error_reporting setting) if you don't set the throw_startup_exceptions option.

The solution for me was to set option throw_startup_exceptions to false until I fix the strict/notice errors in the code.

You can set it in application.ini:

resources.session.throw_startup_exceptions = false

or by calling Zend_Session::setOptions()

Christian P
  • 12,032
  • 6
  • 60
  • 71
1

Clear your browser's cookies. PHP sessions seem to store the SID in a cookie, so when I switched from php 5.3 to 5.4 there seems to have been some problems dealing with existing cookie values for session. simply clearing the session data was not enough- try clearing all session data and also deleting browser cookies.

james
  • 26,141
  • 19
  • 95
  • 113
0

In my case it was just allow write mode for the session directory

carstep
  • 51
  • 4