ERROR msg: session_commit(): Cannot call session save handler in a recursive manner

[Richard Catto]

I get this error on accessing my site:

session_commit(): Cannot call session save handler in a recursive manner

if I refresh the page, it goes away.

The error traces to this code in a class method:

$this->f3->set('SESSION.email',$email);

I start a session in my index.php like this:

$s = new \DB\SQL\Session($dbPDO);

this gets called before I attempt to set a session variable.

Any idea what is happening and how to fix this?

[ved]

Was it working before?

Are you using php >7.1?

This issue may be related.

[Richard Catto]

I didn't use session variables before. using php v7.1.8

[ved]

Yeah it's probably that issue. F3's session handlers seem to be affected by that issue.

If you can, please try your app without using any of F3's session handlers (so, using only plain php sessions) and see if the issue goes away.

[Richard Catto]

Okay, I commented out:

// $s = new \DB\SQL\Session($dbPDO);

and the error isn't coming up.

I'll conduct more tests, see if I can narrow it down.

[Richard Catto]

File: lib/db/sql/session.php

function read($id) {

$this->load(['session_id=?',$this->sid=$id]);

if ($this->dry()) return '';

        /* *** commented out ***

if ($this->get('ip')!=$this->_ip || $this->get('agent')!=$this->_agent) {

$fw=\Base::instance();

if (!isset($this->onsuspect) || $fw->call($this->onsuspect,[$this,$id])===FALSE) {

//NB: `session_destroy` can't be called at that stage (`session_start` not completed)

$this->destroy($id);

$this->close();

$fw->clear('COOKIE.'.session_name());

$fw->error(403);

}

}

        *** end commented out *** */

return $this->get('data');

}

the code that checks if the IP or AGENT has changed destroys the current sesssion, removes the record from the db, and stops execution with a 403.

If you ignore IP / AGENT changes, by commenting out the code which checks this, then the problem does not arise.

this was done just to isolate where in the code the issue occurs.

I think the correct way to fix this would be to destroy the session, and then create a new one, without stopping execution.

On Thursday, August 31, 2017 at 7:00:30 PM UTC+2, ved wrote: