Why Session object destruction failed

Question

I get "Session object destruction failed" when I use session_destroy().

session_start();
if(isset($_SESSION['user_id'])){    
    $_SESSION=array();
    if(isset($_COOKIE[session_name()])){
        setcookie(session_name(),'',0,"/");
    }
    session_destroy();
}

What causes this error?

perhaps because of `$_SESSION=array();` or calling `session_name()` before `session_start()`? not sure which one is right... — LeleDumbo, Dec 18 '11 at 04:19
Only the first two lines make sense, the rest of the code is baffling. I don't think you understand how $_SESSION works. Just call session_start() and use it. — rook, Dec 18 '11 at 04:21
Error: Warning: session_destroy(): Session object destruction failed - it's rather trivial, no session has been started, so you can't destroy it. The `@` operator is not always active, e.g. with error reporting functions. — hakre, Dec 18 '11 at 04:28
Are you using a custom session handler by any chance? Guessing no or you would have mentioned it in the question, but worth a shot. — Corbin, Dec 18 '11 at 04:56
@Corbin: Yes I was, there is no error when I disable my error handler. but I removed the "@" and still get the error (when my handler active) — Mahks, Dec 18 '11 at 05:08
Not a session error handler, but a custom session [save] handler, as registered with session_set_save_handler. — Corbin, Dec 18 '11 at 05:10

hakre · Accepted Answer · 2011-12-18T05:06:44.710

21

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.

edited Dec 18 '11 at 05:06

answered Dec 18 '11 at 04:29

hakre

193,403
52
435
836

1

There is, at least technically, a `session_start()` right at the top of the quoted code. – Jared Farrish Dec 18 '11 at 04:30
Maybe started, but not yet comitted, see [`session_commit`](http://php.net/session_commit). – hakre Dec 18 '11 at 04:34
1

So the answer is to `session_write_close()` before `session_destroy()`...? – Jared Farrish Dec 18 '11 at 04:37
No, technically not because you can't destroy a session that is not active. See [`session_destroy`](http://php.net/session_destroy). The general problem with the question is, that the `@` has been added for some reason and that reason needs to be known to tell what is going on here. Session state can be tricky in edge-cases. – hakre Dec 18 '11 at 04:39
"@" not needed, just an attempt to get around the problem. How can you test for an active session? I thought that the line with isset(used_id would do that. – Mahks Dec 18 '11 at 04:44
So where do you get the error message? In STDOUT? And since when does the error occurs? – hakre Dec 18 '11 at 04:45
Well just remembered, `session_commit` might not unset the session id, so probably this can solve the issue. However, if `session.save_path` is wrong, this won't help either. – hakre Dec 18 '11 at 04:48
1

*"What is STDOUT?"* - STDOUT is *Standard Output*, in PHP that is what the browser displays. Are you seeing the error message in your browser or inside some log files? – hakre Dec 18 '11 at 04:49
Was getting error from log file, turned off my error handling routine and do not get the error anymore! What? – Mahks Dec 18 '11 at 04:51
the error handler get's all errors, including those you try to hide away with the `@` operator - the handler callback is still invoked so (error level 0). Just don't use the `@` operator to "solve" things, use it wisely. In this case, don't use it. Instead check if your `session.save_path` configuration is correct. PHP gives you a hint about an error which you should fix, but you need to first find out what's wrong. – hakre Dec 18 '11 at 04:53
I'm running into the same problem when a session was created and then needs to be destroyed on the same script before it was ever created on the browser. I don't see a solution to this problem here. – LStarky Apr 20 '18 at 18:02
@LStarky: Please - if the code you have is not the same as here - create a new question and give the example with it of what you have there. Also report with that question which session save handler you're using. If it is the same, do not destory a session that has not yet been created. In PHP you can learn about a session state via: [`session_status()`](http://php.net/session_status) – hakre Apr 22 '18 at 07:40

score 1 · Answer 2 · answered Jul 27 '16 at 09:18

In my case I was trying to destroy session before cookie was created. In other words I did something like:

session_start();
...
session_destroy();

So the server didn't have a chance to 'contact' with the browser before destroying the session. Simple solution that worked for me was

session_start();
...
$_SESSION=array();

score 0 · Answer 3 · answered Jan 26 '22 at 08:17

0

Use this code:

if(session_status() === PHP_SESSION_ACTIVE) {
    session_unset();
    session_destroy();
}

answered Jan 26 '22 at 08:17

step

2,254
2
23
45

score -2 · Answer 4 · answered Jun 02 '17 at 10:50

-2

If you are using an autoloader, it may be failing to load a class that is saved in the session.

answered Jun 02 '17 at 10:50

dbagnara

745
6
6

Why Session object destruction failed

4 Answers4

Linked

Related