[ BUG ] Accessing $this->di in model causes connection reset

[quasipickle]

I have a model with a function I'm calling from Volt. In that function, I call $this->di->get('config'). I realize now that's the wrong way to do it, but regardless, whenever that function is called, my connection to the server via my browser gets reset.

I'm not sure how to get more information to attach to this report.

Edit It doesn't appear now that this problem is tied to Volt, but rather tied to accessing $this->di from Model::afterFetch()

[ghost]

Could you please post the code that reproduces the bug? The less code, the better :-)

[quasipickle]

Here's the model causing the problem. More code than is necessary, but I thought I'd give you context.

If I remove the afterFetch() method, or simply comment out the line in that method, then the model and the page loads fine.

<?PHP
namespace App;
use \Phalcon\Mvc\Model\Message;

class File extends \Phalcon\Mvc\Model{

    use \MessagesTrait;

    /*
     * All of the following functions are built-in functions called 
     * automagically at various points by Phalcon
     */

    public function initialize(){
        $this->belongsTo('id','App\Request','request_id',
            [
                'foreignKey'=> [
                    'action'=>\Phalcon\Mvc\Model\Relation::ACTION_CASCADE
                ]
            ]
        );
    }

    # On create, moves the uploaded file from the upload to download directory
    public function beforeCreate(){
        $Config =  \Phalcon\DI\FactoryDefault::getDefault()->getShared('config');

        $uploaded_path    = $Config->dir->upload_dir.$this->name_original;
        $destination_path = $Config->dir->download_dir.$this->request_id.'/'.$this->name;

        if(!$this->_validateFilePath($uploaded_path))
            return FALSE;

        if(!$this->type)
            $this->determineType();
        if(!$this->size)
            $this->determineSize();

        if(!$this->_moveFile($uploaded_path,$destination_path))
            return FALSE;

        return TRUE;
    }

    public function afterFetch(){
        $Config = $this->di->getShared('config');
    }

    /*
     *
     * Helper functions called non-automatically
     *
     */

     private function _validateFilePath($path){
        if($path !== realpath($path)){
            $Message = new Message(
                'The requested file ('.$path.') is not a valid uploaded file.',
                'file'
            );
            $this->appendMessage($Message);
            return FALSE;
        }
        else
            return TRUE;
    }

    private function _moveFile($upload_path,$destination_path){
        if(!@rename($upload_path,$destination_path)){
            $this->appendMessage(new Message(
                    'Error while moving uploaded file to Request-specific directory.',
                    'file'
                )
            );
            return FALSE;
        }
        return TRUE;
    }

    public function determineType(){
        $Config =  \Phalcon\DI\FactoryDefault::getDefault()->getShared('config');
        $path = $Config->dir->upload_dir.$this->name_original;
        $FI = new \finfo();
        $this->type = $FI->file($path,FILEINFO_MIME_TYPE);
    }

    //use this function (found here: http://ca3.php.net/manual/en/function.filesize.php)
    //rather than filesize(), because files may be larger than 2GB
    // function also found in FTPFile
    public function determineSize(){
        $Config =  \Phalcon\DI\FactoryDefault::getDefault()->getShared('config');
        $path = $Config->dir->upload_dir.$this->name_original;

        $this->size = \Lib::getFileSize($path);
    }

    public function getSize(){
        return \Lib::filesizeFormatted($this->size);
    }
}

[ghost]

Sorry, I should have been more clear.

What I need is the code I can run locally to reproduce the bug.

If possible, could you please give me the URL of the repo that I can clone, run and see the crash?

[quasipickle]

Sorry, no - my code isn't in a repo. However, as far as I can tell, this happens whenever I have afterFetch() call a method on $this->di like $this->di->getShared('session') or $this->di->get('view'), so it should be fairly easy to replicate. If not, then the bug must be somewhere else.

[ghost]

One question: won't $this->di be NULL in your afterFetch() method? As far as I understand, Model::find() and company are called statically and you have no chance to call setDI() on the model being fetched from the database.

Is that correct?

[ghost]

Could you please grab the latest 1.3.0 and check whether the bug is still there?

[quasipickle]

Yes, $this->di is NULL. What I'm doing to trigger this problem is not proper code, so a properly built model won't encounter this problem. I brought it up though, because even improper code should cause an error, not a connection loss.

I'll try to install 1.3.0...

[quasipickle]

So I believe I cloned & installed the right branch with git clone git://github.com/phalcon/cphalcon.git -b 1.3.0. phpinfo() still says I have 1.2.1 installed, but the connection no longer gets reset, so I think the problem has been fixed. Thanks for your attention to this.

[niden]

I just need to update the version for 1.3.0

Glad it has been resolved

The contents of this message may contain confidential or privileged
information and is intended solely for the recipient(s). Use or
distribution to and by any other party is not authorized. If you are not
the intended recipient, copying, distribution or use of the contents of
this information is prohibited.

On Thu, Jul 25, 2013 at 3:26 PM, quasipickle notifications@github.comwrote:

So I believe I cloned & installed the right branch with git clone git://
github.com/phalcon/cphalcon.git -b 1.3.0. phpinfo() still says I have
1.2.1 installed, but the connection no longer gets reset, so I think the
problem has been fixed. Thanks for your attention to this.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/911#issuecomment-21578319
.