ID: 43579 User updated by: assid at assid dot com Reported By: assid at assid dot com Status: Open Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 New Comment:
Yes, I reversed it back, but it didnt help (seeing the diff in the patch). Previous Comments: ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ [2008-03-03 12:40:02] jsnyxx at gmail dot com sv4php - have you tried reverting the patch made in the ext/session/mod_files.c? Just an idea but this bug (#42596 (session.save_path MODE option does not work)) was fixed in between the PHP 5.2.4 and 5.2.5 releases. Link is here for patch diff: http://cvs.php.net/viewvc.cgi/php-src/ext/session/mod_files.c?r1=1.100.2.3.2.9&r2=1.100.2.3.2.10&pathrev=PHP_5_2 ------------------------------------------------------------------------ [2008-03-01 21:56:15] sv4php at fmethod dot com I had the chance to test this issue with Assid on his server and we were able to more accurately pin point the issue: 1) the sessions don't time out, instead we're talking about session_name() selectively being ignored (which results in two session cookies, and hence sessions, created) 2) the issue seems to only happen on PHP 5.2.5 without --enable-debug. On 5.2.4 it doesn't happen, on 5.2.5 with --enable-debug we couldn't repro, but this needs more testing. 3) the issue may be hardware/configuration dependent (32-64 bit? OS distro? I don't have those details, Assid could provide them). The Apache server on the tested configuration runs in prefork mode, so it can't be a threading race condition (as far as I know). 4) we reverted the patch for bug http://bugs.php.net/42596 and recompiled 5.2.5 but still were able to reproduce the issue. Since this is the only change in the session module between 5.2.4 and 5.2.5, I have to conclude the issue is related to some other code (somehow..). Description of the reproduce steps. We have userA and userB on different machines, IP-s. They both are given the url to the example with the counter as Assid provided it. Notice the example uses session_name('spheretest'). If a userA refreshes the page alone, he gains session cookie 'spheretest' and the counter works normally. If userB refreshed the page, userA gains a new cookie 'PHPSESSID' and a new session. After userA refreshes few more times, PHP gets back to using the previous 'spheretest' session/cookie. We tested if the issue is related to prematurely starting session *before* the session_name() call. But no, session_id is never defined before the session_name() call. ------------------------------------------------------------------------ [2008-03-01 02:36:28] assid at assid dot com err sorry, session counter reset to 1 on refresh on the previous post. ------------------------------------------------------------------------ [2008-03-01 02:34:58] assid at assid dot com Okay, finally found out how to do valgrind with apache :P During valgrind, phpmyadmin was behaving properly, squirrelmail as i mentioned in my previous post is erratic, but it normally takes time to crash, once it does, then it happens more frequently. I later tried the session script as spherelinx.com/session.php (check phps) This counter was working fine here again. I then decided to visit alternate sites on the server perhaps to create more session files. I visited www.equineindia.com, and then i started hitting on session.php again, voila! session counter was reset to 0 I tried to see if i could simulate more of the sessions disappearing etc, like it going back to the original counter, but it didnt go, (normally you keep hitting refresh, you just might get back). I guess i should have tried more, but the day was just beginning and had to let the public in once again. So i decided, we atleast got the basics of what was causing this, and atleast report this. The valgrind log is available at: http://assid.com/apache1.log Btw: yes apc , and fileinfo from pecl were disabled before I did this. the main page of equineindia refreshes to login.php ; please visit login.phps for the source of the same. Interestingly, the leak summary shows alot of leakage BTW. ------------------------------------------------------------------------ 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=43579&edit=1
