New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

\Phalcon\Mvc\Model based objects trigger error when setting it to \Phalcon\Session\Adapter\Files #2241

Closed
cinu opened this Issue Mar 27, 2014 · 16 comments

Comments

Projects
None yet
9 participants
@cinu

cinu commented Mar 27, 2014

Reproduction code:

<?php

$di = new \Phalcon\DI\FactoryDefault();

class Test {
        protected $protected;
        public $public;

        public function __construct() {
                $this->protected = 'protected';
                $this->public = 'public';
        }
}

class Test2 extends \Phalcon\Mvc\Model {

}

$t1 = new Test();
$t2 = new Test2();

$session = new Phalcon\Session\Adapter\Files();
$session->start();

$session->set('somevar', $t1);
$session->set('somevar', $t2); // <- trigger fatal error:
// PHP Fatal error:  Cannot use the memory manager when the request is shutting down in Unknown on line 0

Phalcon version: 1.3.1

PHP version: 5.5.3, 5.5.9

Result:
Fatal error "Cannot use the memory manager when the request is shutting down"

Expected result:
Save object in session

Broken in 2a80399 commit

I haven't checked other adapters, but I guess they won't work either.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@mruz mruz referenced this issue Mar 28, 2014

Closed

Login #15

@niden niden added the Unassigned label Apr 3, 2014

@nokios

This comment has been minimized.

Show comment
Hide comment
@nokios

nokios Apr 3, 2014

Confirmed... I have the same issue.

use \Phalcon\Session\Adapter\Files;
...
$di->set('session', function () {
    $session = new SessionAdapter();
    $session->start();
    return $session;
});

I realize I don't use this in one of my apps, so I can safely comment it out. Just wanted to add credence to this issue.

nokios commented Apr 3, 2014

Confirmed... I have the same issue.

use \Phalcon\Session\Adapter\Files;
...
$di->set('session', function () {
    $session = new SessionAdapter();
    $session->start();
    return $session;
});

I realize I don't use this in one of my apps, so I can safely comment it out. Just wanted to add credence to this issue.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 3, 2014

Collaborator

This is not a bug, PHP shutdowns the Phalcon module and then it tries to call a Phalcon function in the session shutdown so at that point phalcon cannot wake up again. You can serialize the object before storing it into session, or save it as an array:

$session->set('somevar', serialize($t2)); 
$session->set('somevar', $t2->dump()); 
$session->set('somevar', $t2->toArray()); 
Collaborator

ghost commented Apr 3, 2014

This is not a bug, PHP shutdowns the Phalcon module and then it tries to call a Phalcon function in the session shutdown so at that point phalcon cannot wake up again. You can serialize the object before storing it into session, or save it as an array:

$session->set('somevar', serialize($t2)); 
$session->set('somevar', $t2->dump()); 
$session->set('somevar', $t2->toArray()); 
@nokios

This comment has been minimized.

Show comment
Hide comment
@nokios

nokios Apr 3, 2014

I am not doing anything with the above service after I put it into the DI. The code I have above is all there is. so, I'm not setting anything, merely calling start().

nokios commented Apr 3, 2014

I am not doing anything with the above service after I put it into the DI. The code I have above is all there is. so, I'm not setting anything, merely calling start().

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 3, 2014

Collaborator

This only happens when a complex object is put in session. Could you try again using 1.3.2?

cd cphalcon/ext
git checkout 1.3.2
sudo ./install
Collaborator

ghost commented Apr 3, 2014

This only happens when a complex object is put in session. Could you try again using 1.3.2?

cd cphalcon/ext
git checkout 1.3.2
sudo ./install
@nokios

This comment has been minimized.

Show comment
Hide comment
@nokios

nokios Apr 3, 2014

Confirmed that 1.3.2 does not repeat the issue. Again, I must stress, for me, I am only setting the session into the DI, nothing else. I do not know if there are any problems actually using the session object.

Sorry, I spoke too soon. I just installed 1.3.2 and am still getting the following error:
PHP Fatal error: Cannot use the memory manager when the request is shutting down in Unknown on line 0

Code (the ONLY code causing the issue, I'm not setting any session data):

use \Phalcon\Session\Adapter\Files as SessionAdapter;
...
$di->set('session', function () {
    $session = new SessionAdapter();
    $session->start();
    return $session;
});

When I comment this out, the error goes away.

Summary

  • 1.3.0 - segfault error, My app does not function.
  • 1.3.1 & 1.3.2 - PHP Fatal error: Cannot use the memory manager when the request is shutting down in Unknown on line 0, but my app appears to function (again, I'm not using the session item for anything).

Important: Both issues clear up if I comment out the session item in the DI.

nokios commented Apr 3, 2014

Confirmed that 1.3.2 does not repeat the issue. Again, I must stress, for me, I am only setting the session into the DI, nothing else. I do not know if there are any problems actually using the session object.

Sorry, I spoke too soon. I just installed 1.3.2 and am still getting the following error:
PHP Fatal error: Cannot use the memory manager when the request is shutting down in Unknown on line 0

Code (the ONLY code causing the issue, I'm not setting any session data):

use \Phalcon\Session\Adapter\Files as SessionAdapter;
...
$di->set('session', function () {
    $session = new SessionAdapter();
    $session->start();
    return $session;
});

When I comment this out, the error goes away.

Summary

  • 1.3.0 - segfault error, My app does not function.
  • 1.3.1 & 1.3.2 - PHP Fatal error: Cannot use the memory manager when the request is shutting down in Unknown on line 0, but my app appears to function (again, I'm not using the session item for anything).

Important: Both issues clear up if I comment out the session item in the DI.

@dlusignan

This comment has been minimized.

Show comment
Hide comment
@dlusignan

dlusignan Apr 7, 2014

Does it mean that using complex object in the session object is a bad practice or not ?

dlusignan commented Apr 7, 2014

Does it mean that using complex object in the session object is a bad practice or not ?

@nokios

This comment has been minimized.

Show comment
Hide comment
@nokios

nokios Apr 9, 2014

Just to be sure, I've updated my previous comment. It appears that \Phalcon\Session\Adapter\Files is unusable from 1.3.0 onward.

nokios commented Apr 9, 2014

Just to be sure, I've updated my previous comment. It appears that \Phalcon\Session\Adapter\Files is unusable from 1.3.0 onward.

@cinu

This comment has been minimized.

Show comment
Hide comment
@cinu

cinu Apr 9, 2014

In my case updating to 1.3.2 solves the problem (just remember to run ./install from ext directory instead of build).

Reproduction code from first post is broken now (1.3.2):

PHP Fatal error:  Uncaught exception 'Phalcon\DI\Exception' with message 'Service 'db' was not found in the dependency injection container' in [no active file]:0
Stack trace:
#0 [internal function]: Phalcon\DI->getShared('db')
#1 [internal function]: Phalcon\Mvc\Model\Manager->getReadConnection(Object(Test2))
#2 [internal function]: Phalcon\Mvc\Model->getReadConnection()
#3 [internal function]: Phalcon\Mvc\Model\MetaData\Strategy\Introspection->getMetaData(Object(Test2), Object(Phalcon\DI\FactoryDefault))
#4 [internal function]: Phalcon\Mvc\Model\MetaData->_initialize(Object(Test2), 'test2-test2', 'test2', NULL)
#5 [internal function]: Phalcon\Mvc\Model\MetaData->readMetaDataIndex(Object(Test2), 0)
#6 [internal function]: Phalcon\Mvc\Model\MetaData->getAttributes(Object(Test2))
#7 [internal function]: Phalcon\Mvc\Model->serialize()
#8 {main}
  thrown in [no active file] on line 0

cinu commented Apr 9, 2014

In my case updating to 1.3.2 solves the problem (just remember to run ./install from ext directory instead of build).

Reproduction code from first post is broken now (1.3.2):

PHP Fatal error:  Uncaught exception 'Phalcon\DI\Exception' with message 'Service 'db' was not found in the dependency injection container' in [no active file]:0
Stack trace:
#0 [internal function]: Phalcon\DI->getShared('db')
#1 [internal function]: Phalcon\Mvc\Model\Manager->getReadConnection(Object(Test2))
#2 [internal function]: Phalcon\Mvc\Model->getReadConnection()
#3 [internal function]: Phalcon\Mvc\Model\MetaData\Strategy\Introspection->getMetaData(Object(Test2), Object(Phalcon\DI\FactoryDefault))
#4 [internal function]: Phalcon\Mvc\Model\MetaData->_initialize(Object(Test2), 'test2-test2', 'test2', NULL)
#5 [internal function]: Phalcon\Mvc\Model\MetaData->readMetaDataIndex(Object(Test2), 0)
#6 [internal function]: Phalcon\Mvc\Model\MetaData->getAttributes(Object(Test2))
#7 [internal function]: Phalcon\Mvc\Model->serialize()
#8 {main}
  thrown in [no active file] on line 0
@nokios

This comment has been minimized.

Show comment
Hide comment
@nokios

nokios Apr 9, 2014

What is the difference in building between these two? At my company, we're trying to upgrade to 1.3.0 or 1.3.1, and we're trying to package it into a .deb file for easy deployment.

nokios commented Apr 9, 2014

What is the difference in building between these two? At my company, we're trying to upgrade to 1.3.0 or 1.3.1, and we're trying to package it into a .deb file for easy deployment.

@cinu

This comment has been minimized.

Show comment
Hide comment
@cinu

cinu Apr 16, 2014

Well, I haven't looked at differences between those install scripts, but in my case building with ext/install solves this issue, whereas building with build/install doesn't.

cinu commented Apr 16, 2014

Well, I haven't looked at differences between those install scripts, but in my case building with ext/install solves this issue, whereas building with build/install doesn't.

@mauriciotozo

This comment has been minimized.

Show comment
Hide comment
@mauriciotozo

mauriciotozo May 16, 2014

I'm having the same problem. And the bad is that it affects other projects that do not use Phalcon. Because of this I will not be able to use the Phalcon in my project.

mauriciotozo commented May 16, 2014

I'm having the same problem. And the bad is that it affects other projects that do not use Phalcon. Because of this I will not be able to use the Phalcon in my project.

@dlusignan

This comment has been minimized.

Show comment
Hide comment
@dlusignan

dlusignan May 16, 2014

For me, downgrading to 1.3.0 solve the problem.

dlusignan commented May 16, 2014

For me, downgrading to 1.3.0 solve the problem.

@mauriciotozo

This comment has been minimized.

Show comment
Hide comment
@mauriciotozo

mauriciotozo May 16, 2014

I found out the problem occurs only with xdebug enabled.

mauriciotozo commented May 16, 2014

I found out the problem occurs only with xdebug enabled.

@mruz

This comment has been minimized.

Show comment
Hide comment
@mruz

mruz Jun 4, 2014

Contributor

@nokios /ext directory contain the actual code, /build directoy contain slightly optimized source code to build Phalcon for 32/64 bit PHP and is regenerated from /ext by Phalcon team from time to time (eg. for every stable release). Readme: Build Directory.
I think it works properly now (in the latest 1.3.2/ext).

Contributor

mruz commented Jun 4, 2014

@nokios /ext directory contain the actual code, /build directoy contain slightly optimized source code to build Phalcon for 32/64 bit PHP and is regenerated from /ext by Phalcon team from time to time (eg. for every stable release). Readme: Build Directory.
I think it works properly now (in the latest 1.3.2/ext).

@maxowar

This comment has been minimized.

Show comment
Hide comment
@maxowar

maxowar Sep 18, 2014

If you build your own simple session handler (even with session_set_save_handler()) that extends Phalcon\Session\Adapter, there isn't any problem saving objects of type Phalcon\MVC\Model, that in fact already implents \Serializable interface, like any other object in session.

so you can do

$session->set('model_obj', $model); // ...without calling serialize() that cause a double serialization

and then

$obj = $session->get('model_obj'); 

You can even setup a shutdown function to save some data in session at the very last moment when closing php request/process and it works because you are still in PHP code world.

:-|

maxowar commented Sep 18, 2014

If you build your own simple session handler (even with session_set_save_handler()) that extends Phalcon\Session\Adapter, there isn't any problem saving objects of type Phalcon\MVC\Model, that in fact already implents \Serializable interface, like any other object in session.

so you can do

$session->set('model_obj', $model); // ...without calling serialize() that cause a double serialization

and then

$obj = $session->get('model_obj'); 

You can even setup a shutdown function to save some data in session at the very last moment when closing php request/process and it works because you are still in PHP code world.

:-|

@sergeyklay sergeyklay removed the Unassigned label Dec 17, 2016

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Apr 16, 2018

Thank you for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please feel free to either reopen this issue or open a new one. We will be more than happy to look at it again! You can read more here: https://blog.phalconphp.com/post/github-closing-old-issues

stale bot commented Apr 16, 2018

Thank you for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please feel free to either reopen this issue or open a new one. We will be more than happy to look at it again! You can read more here: https://blog.phalconphp.com/post/github-closing-old-issues

@stale stale bot added the stale label Apr 16, 2018

@sergeyklay sergeyklay closed this Apr 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment