The PHP docs clearly mention this since 5.0.5. Why Drupal was wrorking with previous versions? Mystery. But 5.2 seems to have brought this up.

There was another issue out of this but that was too littered.



Before I forget. Can this break something? Unlikely. If you have an object that changes $user in the destructor or save something into SESSION then that will break, but objects especially objects with destructors (ie. non stdClass objects) is alien to Drupal world. This matter because we will need to port this back to every Drupal we care of.

new702 bytes

Some sneaky chars in my patch which are invisible to my editor :(

subscribe to issue

Forgot to say thanks for ajk who did a lot of gruntwork and uptimebox who lended access to a broken box.

OK, I went through the old issue and where people stated that certain things weren't fixed by this patch (notably cron and update.php) I tested this patch and it worked ok. So that's good.

For those that said "it didn't work in other places", sorry I could not test that, not enough information! So, if you are going to reply to this issue please be verbose and give us pages that don't work. One liners that say "didn't work" aren't helpful to debugging / testing.

Have you guys looked at this for the file_transfer($source, $headers) function. When a user is downloading large files the session is locked and all other pages wait for the page to finish downloading.

I think we need to call session_write_close(); before the file start downloading.

Nax, that's a whole different issue.

thanks chx for your patch. I've tried it and it seems to work fine.

I had tested the same line, but I had this line in the index.php after the drupal_bootstrap(). Presumable this was too late, so I had problems with this.

I'm using this now and I'll report if any troubles occur again.


Just subscribing.

Status:Needs review» Reviewed & tested by the community

If fago, the original reporter also says it's OK (and ajk did a very through testing on an also known-to-broken box) then we are good to go.

Assuming this will not work for 4.7.... subscribing.

Once this goes into HEAD we'll backport the fix to 4.7 (and maybe 4.6)

laura s: I've manually merged this patch with my 4.7 and everything seems to be in order.

I am one of those who CAN reproduce the behavior every-time under

Mac OS X 10.4.8
PHP5.2.0 ( Release 3)
MySQL 5.0.24a-standard

but only when using the mysql driver. The problem goes away as soon as I specify the mysqli driver.

Therefore I am dubious that the proposed "patch" to register a shutdown function in sess_read is the right approach.

My 2cents.

this patch fixed it for me.

by using mysqli the issue doesn't occur, because of the mysqli db layer of drupal, which does already address this problem the same way

I was having that problem. this patch fixed it.

Fabio Varesano

new632 bytes

Attached is Karoly's patch rolled against DRUPAL-4-7. Fixed the issue with Drupal 4.7.4 running on PHP 5.2.0 + Apache 2.2.3 + MySQL 4.1.20.

a bit more feedback: i applied the fix by hand to two 4.7 sites, one running php 5.1, the other php 5.2. both are working fine now.

by using mysqli the issue doesn't occur, because of the mysqli db layer of drupal, which does already address this problem the same way

indeed, adding the snippet from to solves the issue.

So my question is, why adding the same patch to a different file ( Doesn't that mean that session_write_close is getting called twice if I apply the patch AND use mysqli?

Version:x.y.z» 5.0-beta1

Status:Reviewed & tested by the community» Fixed

Committed to HEAD.

Version:5.0-beta1» 4.7.4
Status:Fixed» Reviewed & tested by the community

Please also apply the patch in #18 to the DRUPAL-4-7 branch.

Just encountered this problem by upgrading to latest WAMP on test box (contains PHP 5.2.0) in drupal 4.7. The patch in #18 fixed the problem.

Status:Reviewed & tested by the community» Fixed


this works for me as well on latest WAMP5 on windows vista

new1.55 KB

after discussion this on #drupal-support, I created a new patch file that adds register_shutdown_function to and removes same call from

This patch file is for drupal4.7.4. It shouldn't be hard to create one for drupal5.beta-1

Version:4.7.4» 5.x-dev
Priority:Critical» Normal
Status:Fixed» Reviewed & tested by the community
new782 bytes

No need to two pieces indeed... your patch moved it to sess_read for 4.7 but that's already committed. Please apply this patch to 4.7 and HEAD too.

Version:5.x-dev» 4.7.x-dev

Committed to CVS HEAD.

Just wanted say thanks for this patch, it saved my hide when my host updated!

There is still a problem when trying to attach a file. When a file is selected and the submit button is pressed, I get kicked out of the system. The problem with PHP 5.2.0 is not completely solved.
Anybody looking at this?
Or is this issue handled in another node as this problem is likely to be in the upload module?

I applied only patch #18 and was able to remain logged in and upload files.

My system is:
Apache/1.3.37 (Unix)

OK, my file uploading problem is solved too.
The problem was the combination of 2 patches. I removed the very first patch which was issued for this problem.
Currently only using patch sess_patch_47 and everything is working fine again.

Hi someone told me that this patch could help me with problem decsribed here (imce upload files problem) I have applyed this patch but nothing has changed and by checking the uploading attachments for node also doesn't work. drupal is 4.7.3 php is 5.2 apache 1.actual (don't know precise version) and Iam using mysqli extension

Status:Reviewed & tested by the community» Patch (to be ported)

I think this is the right status.


Status:Patch (to be ported)» Fixed

if there is no work neccessary RTBC is IMO the right status. applied

if there is no work neccessary RTBC is IMO the right status. applied

Version:4.7.x-dev» 4.6.10
Status:Fixed» Patch (to be ported)

Subscribing, so it can be ported to 4.6.x

Status:Patch (to be ported)» Needs review
new646 bytes

Here it is. I've tested and it seems right.
BTW: can someone create a 4.6.x-dev please? Thanks

Status:Needs review» Reviewed & tested by the community

I received the following message:

I described my recent problem in
I was guided to your patch and was succesfull in installing. Now I can
stay logged and work with Drupal 4.6.6 site.

Php 5 has been installed about a year ago, Drupal 4.6.6 half a year ago,
server last booted more than a month ago. Nobody didn't do nuthin' and
suddenly this problem occurs.

With best thanks Timo Sylvänne

Marking this RTBC.

Version:4.6.10» 4.6.x-dev

As mentioned at:
Troubleshooting FAQ > Login problems on PHP 5.2

I applied patch at:
which is comment #27 of this thread.

After applying the patch the problem persists when using Firefox 2.0. With konqueror I don't have the problem, but I'm not sure if it is because of the patch, or it worked before (I didn't test it with konqueror before applying the patch).


PS: shoudn't apache be restarted after applying the patch?

Version:4.6.x-dev» 4.7.4

I manually applied this patch to my system (freshly installed 4.7.4) For less php-aware users, can we roll a 4.7.4 version of this
patch, since the patch didn't want to apply since it was from the 5.0beta branch ?

Also, to the poster who asked "why previous versions worked", the answer is probably that they were using an earlier version of PHP, since I first saw the problem after updating PHP, rather than after updating Drupal! - Luckily I updated PHP on my test system first, rather than on a production system, of which I have several

Version:4.7.4» 4.6.x-dev

this patch is already committed for 4.7 and will appear in 4.7.5.

Can someone look at #40? It has a small patch needing some commit...

Status:Reviewed & tested by the community» Fixed

appleid to 4.6

What behavior is this supposed to fix ?

Status:Fixed» Closed (fixed)

I upgraded a site running on PHP 4.3.11 from 4.7 to 5.0 only to find myself completely unable to login. I checked and no rows were being stored in the sessions db table. This was pretty disturbing and after experimentation with numerous cookie/domain setting combinations, I have discovered that commenting out this change fixed the problem.

This might also be causing the issue at

Title:Session handler executed after $user object is destructedapplying this patch

I have no idea how to apply this. I have applied patches using cygwin before with specific files, but this is over my head.

Any help is appreciated.

Title:applying this patchSession handler executed after $user object is destructed

Reverting title

Manually applied patch in #40 to 4.6.5 for a perfect fix...
Thank you Magico

Version:4.6.x-dev» 6.14

I got to this page one way or another, but my problem is with Drupal 6.14. I keep getting kicked back to the login form whether I put in the right login information or not. It never seems to register. It worked fine for months and now I can't access the admin at all. I think that it has to do with the session in some way or another like this issue, but there is not a patch for drupal 6.14 for this.

Where should I start?

Title:Session handler executed after $user object is destructed Access denied You are not authorized to access this page.
Category:bug» support
Status:Closed (fixed)» Active

I am new to drupal.
I installed drupal6 in karmic koala,using apache.
I started working too.But never used mysql(not yet started using databses.)
I create pages etc,etc...
Now i got a problem, I logged out and tried to login again i get the screen of anonymous user and saying that
" Access denied You are not authorized to access this page."i searched to fix this problem and browsed
many forums but could nt get what i need.I hope there is no problem with mysql.
i.e.,i cannot enter in the admin window pls someone help.

Title: Access denied You are not authorized to access this page.Session handler executed after $user object is destructed
Status:Active» Closed (fixed)

@ #55 - you replied to a closed report about a very specific bug. Please open a new topic.