Closed (fixed)
Project:
Drupal core
Version:
6.14
Component:
base system
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
10 Nov 2006 at 00:11 UTC
Updated:
8 Jun 2014 at 02:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
chx commentedBefore 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.
Comment #2
chx commentedSome sneaky chars in my patch which are invisible to my editor :(
Comment #3
AjK commentedsubscribe to issue
Comment #4
chx commentedForgot to say thanks for ajk who did a lot of gruntwork and uptimebox who lended access to a broken box.
Comment #5
AjK commentedOK, 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.
Comment #6
NaX commentedHave 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.Comment #7
chx commentedNax, that's a whole different issue.
Comment #8
fagothanks 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.
Comment #9
satori1984 commented+1
Just subscribing.
Comment #10
chx commentedIf 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.
Comment #11
laura s commentedAssuming this will not work for 4.7.... subscribing.
Comment #12
AjK commentedOnce this goes into HEAD we'll backport the fix to 4.7 (and maybe 4.6)
Comment #13
satori1984 commentedlaura s: I've manually merged this patch with my 4.7 session.inc and everything seems to be in order.
Comment #14
jhm commentedI 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.
Comment #15
drewish commentedthis patch fixed it for me.
Comment #16
fagoby using mysqli the issue doesn't occur, because of the mysqli db layer of drupal, which does already address this problem the same way
Comment #17
fax8 commentedI was having that problem. this patch fixed it.
Fabio Varesano
Comment #18
Arto commentedAttached 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.
Comment #19
drewish commenteda 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.
Comment #20
jhm commentedindeed, 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?
Comment #21
chx commentedComment #22
drummCommitted to HEAD.
Comment #23
Arto commentedPlease also apply the patch in #18 to the DRUPAL-4-7 branch.
Comment #24
FiReaNGeL commentedJust 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.
Comment #25
killes@www.drop.org commentedapplied
Comment #26
Veggieryan commentedthis works for me as well on latest WAMP5 on windows vista
Comment #27
jhm commentedafter 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
Comment #28
chx commentedNo 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.
Comment #29
dries commentedCommitted to CVS HEAD.
Comment #30
arthurf commentedJust wanted say thanks for this patch, it saved my hide when my host updated!
Comment #31
Firewolf commentedThere 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?
Comment #32
ceardach commentedI 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
Comment #33
Firewolf commentedOK, 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.
Comment #34
thepeter commentedHi 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
Comment #35
webchickI think this is the right status.
Comment #36
inforeto commentedSubscribing.
Comment #37
killes@www.drop.org commentedif there is no work neccessary RTBC is IMO the right status. applied
Comment #38
killes@www.drop.org commentedif there is no work neccessary RTBC is IMO the right status. applied
Comment #39
magico commentedSubscribing, so it can be ported to 4.6.x
Comment #40
magico commentedHere it is. I've tested and it seems right.
BTW: can someone create a 4.6.x-dev please? Thanks
Comment #41
magico commentedI received the following message:
Marking this RTBC.
Comment #42
magico commentedComment #43
Mguel commentedAs mentioned at:
Troubleshooting FAQ > Login problems on PHP 5.2
I applied patch at:
http://drupal.org/node/93945#comment-155161
which is comment http://drupal.org/node/93945#comment-155161>#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?
Comment #44
relyod commentedI 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
Comment #45
killes@www.drop.org commentedthis patch is already committed for 4.7 and will appear in 4.7.5.
Comment #46
magico commentedCan someone look at #40? It has a small patch needing some commit...
Comment #47
killes@www.drop.org commentedappleid to 4.6
Comment #48
Chill35 commentedWhat behavior is this supposed to fix ?
Comment #49
(not verified) commentedComment #50
ChrisKennedy commentedI 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
Comment #51
kweisblatt commentedI 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.
Comment #52
asimmonds commentedReverting title
Comment #53
Clemens commentedManually applied patch in #40 to 4.6.5 session.inc for a perfect fix...
Thank you Magico
Comment #54
shayne1012 commentedI 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?
Comment #55
siva.thanush commentedHi,
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.
-THANKS AND REGARDS
Comment #56
heine commented@ #55 - you replied to a closed report about a very specific bug. Please open a new topic.
Comment #57
DocDJ-forum commentedUsing 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?
regards,
DJ