Why Session Object Destruction Failed

Why Session object destruction failed

Error:

Warning: session_destroy(): Session object destruction failed

It's rather trivial, no session has been started object has been comitted, so you can't destroy it.

The @ operator is not always active, e.g. with error reporting functions.

Edit:

1) What causes this error?

This error is normally caused when PHP tries to delete the session file, but it can't find it.

In your case with session_destroy there is only one place in PHP which causes this. That's when the session.save_handler (see as well session_set_save_handler) returns FALSE for the destroy action. This can depends which type of save-handler you use, the default one is files. With that one, when the session.save_path setting is wrong (e.g. not an accessible directory), this would cause such an error.

2) Why would the "@" not be suppressing the error?

That depends how the output is created and on PHP configuration. @ does not always work. For example callbacks registered with set_error_handler will still receive these messages.

PHP - Session object destruction failed

The problem

Finally I was able to find the problem. Basically it comes from Symfony itself since by default seems that it also implements kind of garbage collection logic in Symfony/Component/HttpFoundation/Session/Storage/Handler/StrictSessionHandler.php

public function gc($maxlifetime)
{
    return $this->handler->gc($maxlifetime);
}

This wouldn't be a problem if /var/lib/php/sessions/ directory belongs to the same user defined in php.ini or if it has read permissions, but by default that directory belongs to root user and is not readable (so files cannot be listed). This causes an exception when Symfony tries to call the garbage collector on current session handler.

---

The solution

There are two solutions: setting

session:
    gc_probability: ~

in Symfony config.yml or adding read permission to PHP sessions directory (or eventually change relative user using the same defined in php.ini). Hope it might help someone.

Warning: session_regenerate_id(): Session object destruction failed in

I think you see the warning because "session_regenerate_id(true)" tries to delete the old session, but the session maybe isn't written at this point. PHP will write the session-file at the end of the script, at the mean time the session values are only in memory. This is also the reason why we use session_write_close or exit after a header redirect, so that the session is written already at this point.

Maybe you can check if the session is available before you try to delete it? e.g.: https://github.com/yiisoft/yii/commit/45d6a7d51be2ea12a935a94511290cb9670706d9

PHP session_destroy() warning Session object destruction failed

Problem solved. The thing that i did was to empty the session and regenerate the id, then destroy it. I don't fully understand the problem, but it kinda does the job:

<?php    
session_start();

if(isset($_SESSION['id_client']) &&  isset($_POST['ok'])){
    $_SESSION=array();
    session_regenerate_id(); 
    session_destroy();
    echo 1;
}
?>

session_regenerate_id(): Session object destruction failed, when running site via security scanners?

Ofcourse, I could just ignore it and clear the error log (when I've finished scanning my site), but I'm just curious and would like to know why (and if there is a 'fix')?

Upgrade your PHP version to the current stable one: PHP 5.4.7.

Run the security checks again. If the error still happens (which I highly doubt), this needs further inspection. In that case (and even earlier) you should have added your session configuration (it is larger than you might think) to the question.

Also the code which is triggering this is unknown. The function session_regenerate_id() is normally used in the context of the session management.

Because the concept of session is not that easy to grasp many developers (incl. me) do errors in that field more often. Some useful debugging functions:

• session_status
• headers_list

---

Related Topics