ID: 43579
Updated by: stas@php.net
Reported By: assid at assid dot com
Status: Open
Bug Type: Session related
Operating System: Debian etch
PHP Version: 5.2.5
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2008-03-01 02:36:28] assid at assid dot com
err sorry, session counter reset to 1 on refresh on the previous post.
------------------------------------------------------------------------
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