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:
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 :| Previous Comments: ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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
