Session: Error while trying to free lock for ci_session

We already knew that the close() call is triggering it, that was shown in the stack_trace.txt you attached yesterday(?).

Code:

    protected function _release_lock($code = 0)
    {
        if (isset($this->_redis, $this->_lock_key) && $this->_lock)
        {
            $exists = $this->_redis->exists($this->_lock_key);
            $del = $this->_redis->delete($this->_lock_key);

            if ( !$del)
            {
                $exists2 = $this->_redis->exists($this->_lock_key);

                log_message('error', 'Session: Error while trying to free lock for '.$this->_lock_key . ', code=' . $code . ', del=' . var_export($del,true) . ', exists=' . var_export($exists,true) . ', exists2=' . var_export($exists2,true));
                return FALSE;
            }

            $this->_lock_key = NULL;
            $this->_lock = FALSE;
        }

        return TRUE;
    }

Added exists calls before and after the delete and to print to the delete call's response and $code being passed. This is the message it produces:

Session: Error while trying to free lock for ci_session:7ed553ebbca1ba962394dcc3a0c934e85b1c25c3:lock, code=2, del=0, exists=true, exists2=false

The key exists before the delete call, the delete call returns 0, yet the key is in fact deleted as shown by the second exists call? The only way I've been able to reproduce this semi reliably is to trigger 2 or more concurrent AJAX requests.

According to the Redis documentation delete should return a long if successful or 0 if it fails. Is this also true for keys set to expire? I've never used those before to know what the expected behaviour is in this situation.

Are you reading the same documentation? Nitpicky and possibly irrelevant, but the one I'm reading here says nothing about failures - 0 is rather an "I deleted 0 keys" count.
I may be trying to read between the lines while there's nothing there to read, but if you're not reading the same docs, you may also not be using the same extension ...

Other than that, it is bizzare that delete() would return 0 while still deleting a key, and I see no logic in returning 0 for keys with expiry time, but ... you'd have to verify that. As I said previously - I don't have a Redis instance to test with.

There is the chance of a phpredis bug, especially if you're not using the same extension, or not the latest version.

Either way, that doesn't explain how the exact same issue would be triggered with Memcached too. Unless phpredis has copied code straigh from the memcached extension, that's almost an unimaginable coincidence.