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.

Members fund testing for the Drupal project. Drupal Association Learn more


chx’s picture

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.

chx’s picture

702 bytes

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

AjK’s picture

subscribe to issue

chx’s picture

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

AjK’s picture

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.

NaX’s picture

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.

chx’s picture

Nax, that's a whole different issue.

fago’s picture

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.’s picture


Just subscribing.

chx’s picture

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.

laura s’s picture

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

AjK’s picture

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

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

jhm’s picture

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.

drewish’s picture

this patch fixed it for me.

fago’s picture

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

fax8’s picture

I was having that problem. this patch fixed it.

Fabio Varesano

Arto’s picture

632 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.

drewish’s picture

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.

jhm’s picture

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?

chx’s picture

Version: x.y.z » 5.0-beta1
drumm’s picture

Status: Reviewed & tested by the community » Fixed

Committed to HEAD.

Arto’s picture

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.

FiReaNGeL’s picture

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.’s picture

Status: Reviewed & tested by the community » Fixed


Veggieryan’s picture

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

jhm’s picture

1.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

chx’s picture

Version: 4.7.4 » 5.x-dev
Priority: Critical » Normal
Status: Fixed » Reviewed & tested by the community
782 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.

Dries’s picture

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

Committed to CVS HEAD.

arthurf’s picture

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

Firewolf’s picture

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?

ceardach’s picture

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

My system is:
Apache/1.3.37 (Unix)

Firewolf’s picture

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.

thepeter’s picture

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

webchick’s picture

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

I think this is the right status.

inforeto’s picture

Subscribing.’s picture

Status: Patch (to be ported) » Fixed

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

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

magico’s picture

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

Subscribing, so it can be ported to 4.6.x

magico’s picture

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

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

magico’s picture

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.

magico’s picture

Version: 4.6.10 » 4.6.x-dev
Mguel’s picture

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?

relyod’s picture

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’s picture

Version: 4.7.4 » 4.6.x-dev

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

magico’s picture

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

Status: Reviewed & tested by the community » Fixed

appleid to 4.6

Chill35’s picture

What behavior is this supposed to fix ?

Anonymous’s picture

Status: Fixed » Closed (fixed)
ChrisKennedy’s picture

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

kweisblatt’s picture

Title: Session handler executed after $user object is destructed » applying 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.

asimmonds’s picture

Title: applying this patch » Session handler executed after $user object is destructed

Reverting title

Clemens’s picture

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

shayne1012’s picture

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?

siva.thanush’s picture

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.

Heine’s picture

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.

DocDJ-forum’s picture

Issue summary: View changes

Using Drupal 7, Windows 7 Pro X64, Apache 2.4, PHP 5.6, MySQL. I can login from a remote system using either FF or IE. I can login locally (the system that owns the site) using FF, but IE "ignores" the userid + password that works on the other scenarios. The ID & pw I am using is an administrator account. The site is new and thus has no content.

Any other tips to try?