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