ID: 43579 Comment by: sv4php at fmethod 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:
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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2008-02-28 18:13:40] assid at assid dot com this will be difficult, we provide shared hosting on this box, and will be difficult to just shut it down for that period of time. but lets see what i can do. Can you tell me how exactly do i put the whole apache process through valgrind ? ------------------------------------------------------------------------ [2008-02-28 17:52:40] [EMAIL PROTECTED] The libdl stuff can be ignored, so that looks like a clean valgrind run. But, are you sure the problem happens on the command line? I'd run the entire apache -X through valgrind. You'd need to do it on a quiet machine somewhere that isn't getting hit, of course, so you can control the requests you send to it while valgrind is running. Hit it until you see the problem, then stop and show us that valgrind output from that. ------------------------------------------------------------------------ [2008-02-28 11:40:49] assid at assid dot com Okay ran valgrind (as far as i can understand it) http://assid.com/valgrind.txt I have removed some extensions as i was still testing, but to no success. I hope the log proves useful to you. ------------------------------------------------------------------------ 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