#43579 [Fbk-Opn]: sessions time out on 5.2.5
ID: 43579 User updated by: assid at assid dot com Reported By: assid at assid dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 Assigned To: jani New Comment: Okay i have tried the current release php5.2-200803191930, as of now, it seems good, I will waitfor a day or 2 to see what my users say. Will update here as soon as I get a response. Previous Comments: [2008-03-17 00:43:35] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi A fix for another bug (related to php_admin_value / php_value) was just fixed, and I'm guessing it's causing this session issue as well. So please, try the snapshot! [2008-03-14 09:35:20] assid at assid dot com Yes the assid.com domain has the following in the vhost php_admin_value open_basedir /home/assid:/var/shared:/var/stats:/tmp The other vhosts on the server have similar as well. The other domain: equineindia.com (that uses the login/logout function), has the following: php_admin_value session.gc_maxlifetime 10800 php_admin_value asp_tags 1 php_admin_value max_execution_time 90 php_admin_value session.name eisessid php_admin_value session.auto_start 1 php_admin_value session.cookie_domain .equineindia.com php_admin_value short_open_tag 1 What i did notice, is that if you want to trigger the bug, you refresh a few times on assid.com/session.php, then go to http://www.equineindia.com/login.php and then click login again, then go back to the counter (assid.com/session.php) this somehow makes the bug easier to reproduce. Atleast when running valgrind. When running generally, you just keep refreshing and the bug is triggered. [2008-03-13 13:27:55] [EMAIL PROTECTED] Are you by any chance using php_admin_value/php_value/etc. in some .htaccess file or in your httpd.conf to set any php.ini options? [2008-03-08 20:31:41] assid at assid dot com Actually my original log did contain that. Nevertheless, here you go again i ran 2 rounds www.assid.com/apache.log www.assid.com/apache5.log Hope its helpful. Back to php 5.2.4 for now :| [2008-03-03 23:18:41] [EMAIL PROTECTED] While doing valgrind I'd also recommend setting USE_ZEND_ALLOC=0 in the environment. That would make the engine use only mallocs which would provide much more information to the valgrind. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43579 -- Edit this bug report at http://bugs.php.net/?id=43579edit=1
#43579 [Fbk-Opn]: sessions time out on 5.2.5
ID: 43579 User updated by: assid at assid dot com Reported By: assid at assid dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 New Comment: Yes the assid.com domain has the following in the vhost php_admin_value open_basedir /home/assid:/var/shared:/var/stats:/tmp The other vhosts on the server have similar as well. The other domain: equineindia.com (that uses the login/logout function), has the following: php_admin_value session.gc_maxlifetime 10800 php_admin_value asp_tags 1 php_admin_value max_execution_time 90 php_admin_value session.name eisessid php_admin_value session.auto_start 1 php_admin_value session.cookie_domain .equineindia.com php_admin_value short_open_tag 1 What i did notice, is that if you want to trigger the bug, you refresh a few times on assid.com/session.php, then go to http://www.equineindia.com/login.php and then click login again, then go back to the counter (assid.com/session.php) this somehow makes the bug easier to reproduce. Atleast when running valgrind. When running generally, you just keep refreshing and the bug is triggered. Previous Comments: [2008-03-13 13:27:55] [EMAIL PROTECTED] Are you by any chance using php_admin_value/php_value/etc. in some .htaccess file or in your httpd.conf to set any php.ini options? [2008-03-08 20:31:41] assid at assid dot com Actually my original log did contain that. Nevertheless, here you go again i ran 2 rounds www.assid.com/apache.log www.assid.com/apache5.log Hope its helpful. Back to php 5.2.4 for now :| [2008-03-03 23:18:41] [EMAIL PROTECTED] While doing valgrind I'd also recommend setting USE_ZEND_ALLOC=0 in the environment. That would make the engine use only mallocs which would provide much more information to the valgrind. [2008-03-03 17:32:34] assid at assid dot com Yes, I reversed it back, but it didnt help (seeing the diff in the patch). [2008-03-03 17:31:32] assid at assid dot com It seems whenever I run http://assid.com/session.php (source - http://assid.com/session.phps), if i refresh enough number of times and at odd times, i end up with a new session of PHPSESSID (it also jumps back and forth). I am trying to figure out WHY its starting that session, when the script EXPLICITLY has a session name set to spheretest Maybe that can help us pinpoint what to check? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43579 -- Edit this bug report at http://bugs.php.net/?id=43579edit=1
#43579 [Fbk-Opn]: sessions time out on 5.2.5
ID: 43579 User updated by: assid at assid dot com Reported By: assid at assid dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 New Comment: Any suggestions on the options / how to use valgrind without learning the whole thing. Perhaps the cli cmd to run ? I am starting to think this isnt limited to session related. phpMyAdmin as i mentioned starts acting very very strangely here. Due to the lack of knowledge of valgrind, i can try and see if i can try removing an extension to see if it makes any difference, while retaining atleast the basic ones that i DO need. If i can get the valgrind options (exact cli commands ) to use, that would be great. Previous Comments: [2008-02-28 06:07:18] [EMAIL PROTECTED] 4 different people on our end have tried to reproduce this without any success. And no, those memory issues you refer to have nothing to do with this since they were fixed long before that snapshot you tried. At this point you'll need to dig in yourself. Fire up Valgrind and see if you can spot what might be causing the corruption. It could be in some extension that we don't have in any of our environments here. It definitely isn't the session code itself, so it is impossible to diagnose without more information. [2008-02-27 08:19:03] jsnyxx at gmail dot com Hi Rasmus Yes, we can confirm that nothing changed on the box apart from php 5.2.4 - 5.2.5. We found it easier to reproduce the bug once XCache was installed, but the bug still exists even when we remove Xcache, it's just more intermitment. The developer of Xcache thinks this is related to a heap corruption of some sort. See here: http://forum.lighttpd.net/topic/42805 The issue for us seems to be that even though the session file exists on the server (under a private /sessions directory), at some point when the browser sends the cookie with the PHPSESSID header, the server seems to temporarily lose the information stored in the session file and returns a blank _$SESSION variable. However, after a few more refreshes it provides the correct info from the $_SESSION variable again. [2008-02-26 09:32:06] assid at assid dot com Yes, same machine, same everything. Even phpmyadmin dies on me. I just had to move it back. I can apachectl stop; make install; apachectl start ; whenever your online. Since its a production box, i need functionality to work fine, so i moved it back down to 5.2.4 As I said i am available on freenode as Assid [2008-02-26 09:11:13] [EMAIL PROTECTED] There is only a single trivial change to the session extension between 5.2.4 and 5.2.5 and it was to fix http://bugs.php.net/42596 The change is here: http://cvs.php.net/viewvc.cgi/php-src/ext/session/mod_files.c?r1=1.100.2.3.2.9r2=1.100.2.3.2.10pathrev=PHP_5_2diff_format=u I don't see how this change could have caused these problems. Could you please verify that 5.2.4 works under the exact same conditions that 5.2.5 doesn't work? That is, on the same machine, built the same way and running the same code. [2008-02-26 08:27:56] assid at assid dot com Hrm, strange, i dont use xcache. But yeah session integrity is messed up. Looks like we gotta wait for 5.2.6 and hope the developers fixed that bug. It does seem php5.2-200802241730 is still not done, as a matter of fact, the session file in -dev seems to disappear, whereas atleast in 5.2.5 it remains. (very little testing in -dev btw). So its gone from bad to worse. - Data integrity ? - Another important note, is that phpmyadmin acts super strange as well. The css i believe is generated on the fly, that goes awry and sql queries start yielding no results. I am not sure if this is session related. or not! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43579 -- Edit this bug report at http://bugs.php.net/?id=43579edit=1
#43579 [Fbk-Opn]: sessions time out on 5.2.5
ID: 43579 User updated by: assid at assid dot com Reported By: assid at assid dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 New Comment: okay here you go, 5 hours of sleep helped a bit. http://spherelinx.com/session.php Now refresh this slowly (i mean one F5 per second or 2 seconds), till you hit something like 8-10. Now press F5 rapidly (dont hold), like 5-8 times. You end up with a new counter. Refresh this counter slowly, and again repeat the above step. Sometimes you get it to go back to the older counter. reproduce code: http://spherelinx.com/session.phps phpinfo - http://spherelinx.com/phpinfo.php From my guess, session_name fails or causes some kind of glitch Previous Comments: [2008-02-25 01:28:12] [EMAIL PROTECTED] Many people, including myself, are running SquirrelMail quite fine on 5.2.5 without any sort of session problems. The fact that it also happens in other applications points to a general problem on your end. Sessions are really simple. There are 3 parts to an active session. 1. Your browser sends a session cookie 2. The PHP script that receives the cookie calls session_start() 3. session_start() reads the session data from the session data So, to debug this, look at each part. Install something like the LiveHTTPHeaders Firefox extension and make sure the cookie is being sent. Second, make sure there is a session_start() call in the receiving code. And third, check to make sure that the session data is in the session data store. If you are using the file-based session store, match the session cookie to the session filename and watch it as you click around. Does it suddenly disappear? If so, figure out why. Also check all your session.* settings and if you have multiple servers behind any sort of load balancer, a per-server file-based session store obviously won't work. NFS-based stuff can also cause problems for a file-based session store. You can also write your own very simple trivial session test to verify that sessions are working at all on your setup. [2008-02-24 20:23:25] assid at assid dot com The problem is I didnt make squirrelmail. So i am not sure of what i can provide as the reproducable script. I am using the current stable release. I wanted to give something else to my users in the meantime, so i tried horde, and well, that seems to have session timeout issues as well. [2008-02-24 20:10:03] [EMAIL PROTECTED] Please provide a short reproducing script. [2008-02-24 19:16:31] assid at assid dot com I decided to try and give php5.2-200802241730 a try to see perhaps if the bug is know and rectified. I know still have the session time outs, except now its worse. Instead of being able to continue after clicking on the folder on the left side, it now logs out totally, effectively destroying the session. [2008-02-11 03:45:29] jsnyxx at gmail dot com We've found similar problems -- see our report here: http://xcache.lighttpd.net/ticket/163 (We initially thought that it was Xcache, but that doesn't seem to be the case now). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43579 -- Edit this bug report at http://bugs.php.net/?id=43579edit=1
#43579 [Fbk-Opn]: sessions time out on 5.2.5
ID: 43579 User updated by: assid at assid dot com Reported By: assid at assid dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 New Comment: The problem is I didnt make squirrelmail. So i am not sure of what i can provide as the reproducable script. I am using the current stable release. I wanted to give something else to my users in the meantime, so i tried horde, and well, that seems to have session timeout issues as well. Previous Comments: [2008-02-24 20:10:03] [EMAIL PROTECTED] Please provide a short reproducing script. [2008-02-24 19:16:31] assid at assid dot com I decided to try and give php5.2-200802241730 a try to see perhaps if the bug is know and rectified. I know still have the session time outs, except now its worse. Instead of being able to continue after clicking on the folder on the left side, it now logs out totally, effectively destroying the session. [2008-02-11 03:45:29] jsnyxx at gmail dot com We've found similar problems -- see our report here: http://xcache.lighttpd.net/ticket/163 (We initially thought that it was Xcache, but that doesn't seem to be the case now). [2007-12-12 10:53:02] assid at assid dot com Description: I tried upgrading to php 5.2.5 from 5.2.4 and ever since i did that my sessions have been acting strange. It seems most noticable using squirrelmail. Downgrading back to 5.2.4 seems to have fixed this issue, so its definitely something on how 5.2.5 handles sessions Reproduce code: --- http://spherelinx.com/phpinfo.php http://assid.pastebin.com/f7ba83639 -- yes i know certain configure options have been deprecated. but using the same config.nice for both Expected result: session management similar to 5.2.4 where it doesnt just timeout for no apparent reason. -- Edit this bug report at http://bugs.php.net/?id=43579edit=1
