With php 5.2.0 the userid of every session will be set to uid 0. This occurs because the global user object is not available in the sess_write() session handler.

So you can successfully login however at the next page you will be uid 0 aigain.

I've found this in the php docs to session_set_save_handler():

Write and Close handlers are called after destructing objects since PHP 5.0.5. Thus destructors can use sessions but session handler can't use objects. In prior versions, they were called in the opposite order. It is possible to call session_write_close() from the destructor to solve this chicken and egg problem.

However with php 5.1.x everything was fine. Probably the new memory manager in php5.2.0 changed things.

I tried adding a call to session_write_close() and it really solved all problems :)
The mysqli db layer seems to already addresss this issue for itself (line 87)

Note: This bug affects every drupal version.

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


alexmarkley’s picture

Thanks fago! I've been banging my head up against this problem for the past several hours.

The patch works like a charm. +1 from me. :)


neclimdul’s picture

This doesn't seem to cause any adverse behavior in 5.1.6.

My only comment would be that we might want to comment explaining why we are explicitly calling something that would normally be taken care of automatically.

Mike_Waters’s picture

FYI for the initial login POST, the $user object *is* available to sess_write(); the HTTP request resulting from the '302 Found' sent by that initial POST has a problem.

Mike_Waters’s picture

FYI this also affects update.php, and may affect xmlrpc.php and/or cron.php.
Adding session_write_close() at the end of execution in update.php restores update functionality.

cioplus’s picture

Not sure it works with on all areas. It worked for most but the odd place keeps asking for a login. For example I am trying to delete and image node and it goes back to the login node on confirm.

spintbier’s picture

The fix does not work on all areas. I have the problem on other pages on my website too.

fago’s picture

Status: Needs review » Needs work

indeed, the fix works not in all cases. I also tried


but this doesn't help in every case too.

So I can't see an easy solution for this, but
* saving the user object as global array for the session handler (ugly?)
* writing a destructor for the user object..

Mike_Waters’s picture

There's a discussion re. this issue in php bug tracking:

It begins with a complaint that $_SESSION variables can't be added in an object destructor; then the decision is made that "The destructor is executed too late in the shutdown sequence"; changes are made to cvs (and committed at some point to 5.0.5, though I don't see bug 27555 listed in the changelog), then complaints that objects are destructed before the session completes are lodged. Full circle.

fago’s picture

I'm using this dirty fix now. Seems to work better.

cioplus’s picture

Works well. I can't see any other isssues of the same type at the moment that have been due to a PHP5.2 upgrade.

mhreynolds’s picture

I've just noticed the same problem. Before i try the patch, i wanted to throw this out- what version of mysql are you running? my server upgraded to mysql 5.0.26, and then yesterday upgraded php to 5.2.0. At which point I can't get in. Is there anything i should look out for? Can i run the patch on 4.7.3 or 4.7.4 ? thanks.

mhreynolds’s picture

I patched 4.73 and tested it a bit. seems to work fine. thanks very much for the timely help. this is going to affect a *lot* of people in the near future as hosts make the switch.

Dries’s picture

That's quite a dirty fix. I'd prefer to see something more 'clean'. If not, this definitely needs to be documented properly.

Is this a bug in PHP 5.2? Maybe it will be fixed in PHP 5.2.1?

neclimdul’s picture

I installed php 5.2 today and tested the latest Drupal 5 checkout. I was not able to reproduce this. I'm using gentoo and there are patches applied but none should affect this. The only quirk I do have is that php is compiled against MySQL 5 and I'm connecting to a 4.1 database on another computer. If the assertion that $user isn't available in sess_write then this won't matter but if its something else I thought it might be useful information.

Here's my php.ini for reference. http://drupal.pastebin.us/7898 If someone that has this problem could post their php.ini in a location where we can compare it would be useful in determining the issue.

Also, if you look through the 5.2 changelog you will see "Fixed session extension request shutdown order to ensure it is shutdown before the extensions it may depend on" which would imply that they have done work to fix this problem and the problem we address in the db layer. This makes this bug very strange.

shriram_iyer’s picture

42.45 KB

I have the same problem as all you guys..
Here's a copy of my php.ini
Hope you guys find a solution soon cos I need to get this thing back up as fast as possible!

shriram_iyer’s picture

The patch really works! Thanks a bunch fago!

AjK’s picture

Sorry, but currently with neclimdul on this, cannot reproduce.

Install details:-

  • OS: FreeBSD 6.1
  • Apache: 1.3.37
  • MySQL: 5.1.11
  • PHP: 5.2.0

Haven't bothered posting php.ini, it's an "out of the box for 5.2.0", no modifications

AjK’s picture

Something to think on. I have now managed to reproduce this by switching from Apache1 to Apache2.

When sess_write() is initially called $value parameter is empty/null and the $_COOKIE array is empty.

As such, this line if (empty($_COOKIE[session_name()]) && empty($value)) prevents the info being stored to the database.

Also, no cookie seems to be set by PHP for the session as after the redirect sess_read() has a new key.

AjK’s picture

strike that last comment (#18), it was IE not sending cookies back to the server (hence an empty $_COOKIE array). Firefox saves the day. So I'm back to not being able to reproduce this :(

leoburd’s picture

Hello there,

I applied the patch to PHP 5.2.1-dev and it works like a charm. Thanks so much. I really didn't know why I was having problems with user login...


fago’s picture

I've tested with neclimdul's php ini settings - but no success.

I'm using php5.2 (from php.net), with apache2 and mysql 4.1.
Perhaps mysql5 makes the difference?

First I've also thought that this is php bug, however as I've quoted in my first post it's documentated behavior.

chx’s picture

Fago, could you please try with an MySQL 4.1? I know it's big work, but... please :)

AjK’s picture

Just for the record, I have now tried PHP5.2.0 as :-

  • Apache1.3.37 + MySQL 4.1
  • Apache1.3.37 + MySQL 5.1
  • Apache2.2.3 + MySQL 4.1
  • Apache2.2.3 + MySQL 5.1

With all these differing combinations I have tried an out of the box php.ini and I have also tried shriram_iyer paste-bin php.ini
and I cannot reproduce the problem. My test servers are all FreeBSD4.11 or FreeBSD6.1

AjK’s picture

ok, where to go from here. Although fago has pointed us in the direction of some PHP documentation regarding objects and sessions, that doesn't explain why we are not able to reproduce the problem.

In order to see what's really going on under the bonnett, we need to either

  1. be able to reproduce the problem to study it (not managed to do this so far)
  2. or have someone who does have the problem step forward and allow ssh shell access to their machine

If anyone who has this problem and is willing to step forward and help please contact us Chx, Heine, neclimdul or myself (obviously don't publish any access details on this issue thread).

fago’s picture

thanks AjK ;)

So it looks like the mysql version doesn't matter too. But what else?
I'm using Debian Sarge and I'm running php as fastcgi.

alexmarkley’s picture

41.23 KB

Well, scratch my previous follow-up - the application of the first patch has just made the problem more erratic on my site. (In fact, I ended up being forced to downgrade php to 5.1.6 in order to fix my production environment.)

My problem environment was Apache 2.2.3 and php 5.2.0. My php.ini was pretty much out of the box. I don't think any changes were made to it when I downgraded, so I'll post it on the off-chance that it'll do some good. ;)


Mike_Waters’s picture

Weird; if I declare 'global $user' inside drupal_page_footer(), and then end that function with a call to exit() (execution ends there, anyway), the user object is available to sess_write(), and login works (the same as if I had used session_write_close(), as fago suggested initially).

If you're wondering why I would do that, I noticed that the initial login http request sends a 302 response inside drupal_goto(), and that function has an explicit exit() (so I threw it in for the second, redirected request). And I had placed $user declarations inside some other functions so that I could view it's value when stepping through with my debugger (komodo + xdebug), drupal_page_footer() being one of them.

Any ideas as to why this would work? Is php calling the destructor later because the function in which the script exited required the object?

Arto’s picture

I can confirm this issue with Drupal 4.7.4 on a brand-new development environment with PHP 5.2.0 + Apache 2.2.3 + MySQL 4.1.20.

The patch drupal_php5.2.0_session.patch.txt seems to have fixed the issue for now. Will look into alternate implementations.

dvessel’s picture

I'm not 100% sure but I tried Marc Liyanage's php 5.2.0 package for Mac OSX. Ran into tons of other issues so I uninstalled it. Drupal not remembering my login was one of the problems so I found a 5.1.6 package from his forum. By then I had all my configuration problems solved.

Running Apache 1.3.33 on Mac Tiger. Also running MySQL 4.1.2

smattoon’s picture

drupal_php5.2.0_session.patch.txt did the trick for me too! Thank you fago.

Problem was occuring on Solaris 9, mysql 5, drupal 4.7.3

chx’s picture

If noone gives the developers access to a machine where the problem occurs, we can not fix this bug.

Firewolf’s picture

Title: session doesn't keep userid with php5.2.0 » Still a problem with uploading files

The patch worked well for me. The login and kick out problems are gone. I can add content again, accept uploading files.
I administer a research information system with the main feature of keeping references. For, this we are using the biblio module. Adding references is working fine again, but as soon as a file attachment is added, clicking the submit button kicks the user (including admin) out of the system. Back to log in screen again.

Anybody else with this problem? Any solution available already?

fago’s picture

Title: Still a problem with uploading files » session doesn't keep userid with php5.2.0

please don't change the title

gathond’s picture

The second patch did the trick for me.
However I'm using postgresQL, so it seems to me this is not related to the database, or at least if it is in one of the more generic parts of the DB handling.

chx’s picture

Status: Needs work » Closed (fixed)

Continued http://drupal.org/node/93945 . Thanks to those who reported OS and database versions, it seems that it's independent of all those. Keep the other issue clean of those, thanks.

Veggieryan’s picture

fago's dirty fix in #9 worked a charm for me running php 5.2 in WAMP5 1.65 on windows vista


AmirTheSeventh’s picture

Version: x.y.z » 4.7.4

fago's dirty fix in #9 Fixed my problem, MySQL client version: 4.1.10, Used PHP extensions: mysql, Durpal hosted by hosting company, installed using Cpanel 10.9.0-RELEASE-79 with Fantastico, Druoal versiaon 4.7.4

chx’s picture

This thread is closed, and both Drupal 5-dev and 4.7-dev are fixed. Anyone posting more in this thread will be banned for spamming.

virendrapratapsingh’s picture

virendrapratapsingh’s picture

Status: Closed (fixed) » Active

I used patches(#9) but i am unable to solve session problem.

Php version:5.2.5

thanks in advance

Damien Tournoud’s picture

Status: Active » Closed (fixed)

As chx said upper (more than 1 year ago...) this bug was fixed in all versions of Drupal. Please do not reopen old issues. Open a new one and be as verbose as possible about the problem you are facing.