Session handler executed after $user object is destructed

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.

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 http://www.php.net/manual/en/function.session-write-close.php#54838 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.

+1

Just subscribing.

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 session.inc 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
Apache1.3
PHP5.2.0 (www.entropy.ch 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

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 database.mysqli.inc:db_connect to database.mysql.inc:db_connect solves the issue.

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

Committed to HEAD.

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.

applied

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

after discussion this on #drupal-support, I created a new patch file that adds register_shutdown_function to session.inc:sess_read and removes same call from database.mysqli.inc:db_connect.

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

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.

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)
PHP/5.2.0

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

I think this is the right status.

Subscribing.

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

Subscribing, so it can be ported to 4.6.x

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

I received the following message:

I described my recent problem in http://drupal.org/node/101424
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.

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

I applied patch at:
http://drupal.org/node/93945#comment-155161
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).

Thanks,
Mguel

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

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

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

appleid to 4.6

What behavior is this supposed to fix ?

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 http://drupal.org/node/108663#comment-182479

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.

Reverting title

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