php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #20449 sessions randomly fail
Submitted: 2002-11-15 12:28 UTC Modified: 2003-06-09 08:44 UTC
Votes:53
Avg. Score:4.8 ± 0.6
Reproduced:45 of 46 (97.8%)
Same Version:12 (26.7%)
Same OS:17 (37.8%)
From: josh at zebotech dot com Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.3.0-dev OS: redhat 7.3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: josh at zebotech dot com
New email:
PHP Version: OS:

 

 [2002-11-15 12:28 UTC] josh at zebotech dot com
I have seen this bug reported a couple of times.  Forgive me for starting my own but I want to bring this back to the attention of the developers.

I've got a fairly high traffic server.  (30-50K uniques per day)

For the most part, everything works ok.  We get plenty of orders (between 70-90 a day).   However, I also get complaints from people who say they keep losing their cart.

To try and track down what was going on.  I started storing some fairly simple stats from the site.  Here is an example of one sent to me via e-mail from my order.html page.

Person's cart failed?
Referring url is: http://www.t-shirtking.com/cart.php
User Agent is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; Roadrunner)
Cookie output: c93856925c2ed796d3560d3729ebeb60
Other Session: http://www.t-shirtking.com/catalog/136-00813/c93856925c2ed796d3560d3729ebeb60
Other Session: addProduct
new session is: c93856925c2ed796d3560d3729ebeb60

A quick description is as follows.  If they come to the order.html page and the script doesn't see the $_SESSION["cart"] variable, it sends me this message.   It sends me the referring url. (a lot of people hit checkout instead of add to cart for some odd reason, so this is proof that this particular person went through the cart)  Then I grab the user agent to try and narrow down the browsers with problems.  Then I see if the session id is in a cookie.  Then, by looking at their session variable, I can see that they went to cart.php via the given url.  (I store the http_refferer as a session variable on the cart.php page)  Then, to prove to myself that the cart function ran, I store the fact that the person came from the catalog url and did indeed pass the cart command addProduct (via the form post data).  As a last test, I send myself the session_id that order.html is using (to make sure the session wasn't restarted)

So, what can I gather from this....I only give one example.  However, I get about 10 of these messages a day.   I'm sure there are even more than that considering that some people may give up when they notice their cart isn't holding their products and don't bother going to order.html.  As you can tell from above, it is clear that the session id is indeed intact.  Also, I'm actually able to pull information out of the session that was stored on a previous page.  (the addProduct command and the url stored in the session by the cart.php page)  However, the cart variable, which is an object, is no longer there.  (it is a simple object btw.  Just an object with an array in it and a few member functions)

I thought perhaps using the default php session manager, that it was having problems.  So I recently switched it to a mysql based manager.  (just using the session_save_handler).  I still get the issue though. Therefore, I cancel out blaming php's file storage method.

Where is my cart object going?  It happens only randomly.  It also happens only to users of IE. (though 90% of our traffic are IE users)  It happens to IE6.0, IE5.5, IE5.0.   It also happens at any time during the day (meaning, high traffic times and low traffic times) I have also been able to immediately look at my sessions table in the database when I receive a message like the above.  Sure enough, the session is there...it has data...just no cart.

Of course, the biggest problem of all....I can't reproduce the bug to save my life.  I've tested on 10 different machines using a variety of Windows versions and IE versions.  I've tested the cart well over 100 times.  Yet, I never seem to be able to break it.  I even try to add the product that I know the person who did lose the cart was trying to buy.

I'm pretty sure I'm losing orders because of this.  I can't imagine how many people are having issues.

I have tried two things in the last couple of days. One, I downloaded and installed the cvs version of PHP.  I also stopped storing the cart as an object and simply storing it as an array.  Neither of these tests have worked.  I still get the problem.

Right now, we are going to setup a second server and split the traffic among each.  Hopefully this will lower the loss of session data. 

The other wierd thing is that I don't lose the entire session.  Just the part that contains the cart array. (and before that the cart object)  Remember, the cart object had the same array in it that I am storing now.  Perhaps the problem is with storing arrays???

Anyway, this is a major problem.  I've seen it in past bug reports.  The fact is, sessions are unreliable.  And that is a shame.  I see it as mission critical for PHP.  If this doesn't get fixed soon, I guarantee that my client will want to move away from php.  And that to me would be a nightmare.  It is possible that sharing the load on 2 servers will solve my problem.  But I shouldn't have to have a second server when one server is perfectly capable of handling the traffic.  (my server load hovers between 0 and 2.)

My install options are:
./configure --with-apxs=/usr/sbin/apxs --with-config-file-path=/usr/local/lib --disable-debug --with-mysql=/usr

I have apache 1.3.23
Here is a link to my phpinfo() function
http://www.t-shirtking.com/temp/phpinfo.php

Thanks,
Josh Bauguss

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-15 12:59 UTC] rasmus@php.net
What are these other bugs you mention?  Please reference exact bug report numbers.

And, what are you using for your session backend data store?  Using your own db-based data store would probably be a good idea.  See php.net/session_set_save_handler
 [2002-11-15 13:58 UTC] josh at zebotech dot com
I am already using the save handler to use my own mysql backend.  

Please don't close this bug again.  I am using CVS from a build on 11-14-2002.  I still get random session failure.  

Here is a list of other bugs that are related to this.
Bug #19029
Bug #17846
Bug #19972
Bug #19022

As far as I can tell, these other bugs were never fully resolved.

BTW, while I allow php to set a cookie, I don't use it at all.  I manually set session_id by using the session passed via the url.
 [2002-11-15 19:32 UTC] sniper@php.net
Can you add _short_ example script here that shows the problem, as I'm using sessions a lot and never have had any problems with them. Albeit I haven't tried to overload them too much either. Maybe you're doing something that isn't really been thought about when the session extension was written?

 [2002-11-16 20:32 UTC] josh at zebotech dot com
As for an example script...I don't think I could make it short.  However, the script is only a shopping cart. I'm not doing anything out of the ordinary.  It is a simple array of strings.  I try to store the array as a session.  

Like I said before, I've never been able to break it myself.  However, I do see evidence of it breaking. (ie. the e-mail that is sent to me)

I guess it should be possible to write a script that continuously tries to add to cart then checkout and see if it would break that way.  

I will do so and get back to you.  In the meantime, I will change the status of this to feedback.
 [2002-11-17 12:06 UTC] josh at zebotech dot com
ok.  This is really frustrating.  I wrote a script that simulates a cart.  I use fopen once to add something to the cart, and a second time to check the cart.  (I use uniqid to create a session id and pass it through the url)

The script simulates it 100 times.  Then, via a interface and iframes, I have six frames loading the test script.  

See - http://www.t-shirtking.com/temp/testcart.html

This raises the load a little.  However, as you will see, it checks out everytime.

However, this morning I check my e-mail and find a dozen more messages from the order page that tells me someones cart was empty.

Next message, I'm gonna show you my cart.  It isn't too complicated.
 [2002-11-17 12:35 UTC] rasmus@php.net
Your handler isn't very good.  As far as I can tell you never update the expiry value which means that your sessions will randomly (because the gc hook is called on a probability) after 5400 seconds (90 minutes) after initial creation.  A quick fix would be to never expire sessions by setting:
session.gc_probability = 0
In your php.ini file.  Or, better yet, fix your handler to update the expiry time when writing to a session.  This expiry time is supposed to be idle session time, not an absolute the way you have it.

I would suggest letting MySQL handle the timestamp and using a schema that looks like this:

    id char(32) NOT NULL,
    data text,
    ts timestamp,
    PRIMARY KEY (id)

And instead of that ugly INSERT/UPDATE thing you have for your write hook, use:

    $data = addslashes($data);
    mysql_query("replace into $table (id,data) values('$id','$data')")
        or error_log("write: ".mysql_error()."\n",3,"/tmp/errors.log");

The gc hook would just be:

function gc($max_time) {
    global $table;
    mysql_query(
      "delete from $table where UNIX_TIMESTAMP(ts)<UNIX_TIMESTAMP()-$max_time")
      or error_log("gc: ".mysql_error()."\n",3,"/tmp/errors.log");
    return true;
}

But try setting gc_probability to 0 just to verify that this is indeed the cause of the lost sessions.  If it is, then you need to slap yourself hard as the code is doing exactly what you told it to do.
 [2002-11-17 12:36 UTC] rasmus@php.net
Missed a couple of words in the above.  "will randomly be deleted" I meant to write.
 [2002-11-17 12:42 UTC] josh at zebotech dot com
Ok.  I will fix my handler using your suggestions.  I'll get back to you after a few hours of letting it work.

Josh
 [2002-11-17 17:32 UTC] josh at zebotech dot com
I set the gc_probability to 0.  After 5 hours, I got another dozen notifications that the cart failed.  I even got a tech support complaint from a customer.  

My hunch is that the serializer is obliterating the array.  One of the recent things I started to do was to initialize $_SESSION["cart"] = Array(); when they first enter the site.  On the sessions that have problems, the cart variable disappears.  However, other session variables still exist.  

No where on the site do I attempt to destroy the session. 

I'm going to change my | delimiter as I notice that the serializer uses a | as a delimiter.  I wonder if that could be it.  (though, it works most of the time)

I've made the other changes to the handler.  I still see problems though.  Is there any particular user behaviour that could explain it?  I had someone suggest to me that a user double clicking the add to cart button could do it.  I don't see how though.  Not only that, I've tried clicking more than once myself and have never seen the problem.

Josh
 [2002-11-21 09:54 UTC] josh at zebotech dot com
I just noticed something in my session table. 

a:2:{s:4:"cart";N;s:10:"gobackpage";N;}

What does N mean?
 [2002-11-21 15:29 UTC] russ at zerotech dot net
NULL
 [2003-05-09 00:18 UTC] php dot bugs dot krishaven at spamgourmet dot com
My session problems appear to all be caused by the fact that $array1=$array2 doesn't do a "deep copy" as described in bugs:

http://bugs.php.net/bug.php?id=8130
http://bugs.php.net/bug.php?id=21288
http://bugs.php.net/bug.php?id=20993

Personally, I don't think that the previous dismissal of the problem with "This will not be fixed anytime soon. It is a deep seated problem in the implementation and fixing it would cause speed problems and numerous other problems," or considering it a documentation problem are appropriate responses.  I guess I was lucky that this was causing an apache segfault, or who knows how much data this could have corrupted?
 [2003-06-02 17:09 UTC] sniper@php.net
This should be fixed in PHP 4.3.2, so please give it a try.

 [2003-06-09 08:44 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2004-01-16 15:30 UTC] dspice at samys dot com
I was extremely relieved to find this post, as I've been having the identical problem. However, it seems like it's not yet resolved in any practical manner. The same scenario occurs for me: a small but important number of users lose the data in the session arrays (but not the session itself) - I believe when the protocol switches from http to https. I have tried many times on many machines to replicate it; so far of the customers I have been able to get data from, it seems they are all running IE6 on Windows XP, but that could easily just be statistical probability. I've tried to replicate the problem using the exact same IE version number, with no success. I can't tell how many people this is affecting, exactly, but I can tell that it's costing us money. It's reassuring to see other people facing the same problem, but disparaging to see that it's been over a year and this apparent bug still has not been resolved.

Any help would be greatly appreciated.
 [2004-01-16 16:41 UTC] josh at bauguss dot net
I just got the last comment sent to me in my email so I rechecked this bug.  I'm suprised to see that most of the comments that I had posted to this bug are now gone.  I'm also really suprised that this bug report had been suspended.  

Just for the last guys benefit for his comment on this bug...

I wrote my own session handling routine and that completely fixed the problem.  I now don't use any of the session calls built into php.  I also wrote my own serialize/deserialize function.

While I can't prove it at the moment as I don't have time to, I'm pretty sure that the problem with the session handler is with the serialize/deserialize routine used by the session handler.  I seem to remember this being my conclusion way back over a year ago and I think I even provided comments in this bug report that seem to no longer be attached to this bug.  

I can't recall at the moment nor can I risk testing it on my site, but I think when I tried using the serialize/deserialize function in php in my own session manager I ran into the same symptoms of this bug.  When I wrote my own routine, it disappeared and solved my session management woes.

Hope that helps.

Josh Bauguss
 [2004-04-28 18:05 UTC] electricbrunette at hotmail dot com
hello josh

this is jeremy vanbibbers girl allison. just thought i would say hello. was looking for a way to contact jeremy online. sorry bout the bug. hope you like it in your new place. we missed you when you left.
 [2004-07-05 07:16 UTC] webmaster at mytrim dot com
I run a couple of sites with at least 1000 unique users online at any given time. I run 4.3.2 and would estimate that about 5 percent of my users have this problem. It has me wondering, has anyone has experienced this with version 5? Also if the previous poster who developed their own session handler sees this can you please email me or post a url to the code.
 
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue May 30 22:03:41 2023 UTC