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

Reply via email to