Closed Bug 541356 Opened 15 years ago Closed 15 years ago

session lost after restart

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: dwitte)

References

Details

(Keywords: regression)

Attachments

(2 files)

Part 1: Fix AddCookieToList
1.72 KB, patch
sdwilsh
: review+
Details | Diff | Splinter Review
Part 2: Don't batch in AddInternal
11.85 KB, patch
sdwilsh
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20100118 Ubuntu/10.04 (lucid) Minefield/3.7a1pre Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20100118 Ubuntu/10.04 (lucid) Minefield/3.7a1pre what I'm seeing is sites that usually didn't logout before (early chromium-dev/chromium 3, FF 3.5.x), now (current Chromium dev, FF 3.6, and 3.7) loose logins even if Remember Me box is selected but haven't managed to put my finger on it yet, its one of those "I have this strange feeling this wasn't like this before" cases, and a coworker (who just upgraded his mac to firefox 3.6) just mentioned the same, reforcing my beliefs. sites like gmail, identica, etc Reproducible: Sometimes Steps to Reproduce: 1. open gmail.com, login with Remember Me. 2. close browser 3. open gmail again Actual Results: asks for login Expected Results: to be logged in [reed] in IRC suggested to enable NSPR logging for cookies, but I dont know how.
to get debug $export NSPR_LOG_MODULES=all:5
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
sdwilsh, see previous comment.
My guess would be that we are treating something as a session cookie when we shouldn't be. Do you have one site it always happens on?
not always, but then again i havent use FF so intensive to notice so! i'll try it a bit this weekend to see
I see it reliably on livejournal.com (that's what I used to find the regression range). I may have seen it on some other sites, but I don't remember what they were. If I run into them again, I'll make note of them here.
Same problem here, with all sites, including major social networks such as Facebook and Twitter as well as Google sites. Another example are WordPress blogs. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a4pre) Gecko/20100327 Minefield/3.7a4pre
There could be different problems here. The initial reporter said he sees the problem in 3.6 also, but the regression range in comment 2 doesn't include anything fixed in 3.6 (or even 3.6.2; one privacy mode bug that will be fixed in 3.6.3). The initial reporter also sees a problem with Chromium which has nothing in common with Firefox, so that might be a system issue. Comment 7 is seeing it with all sites, earlier commenters only on some. We do know in the past that corruption in the cookies.sqlite file sometimes resulted in the inability to save any cookies. If it's that kind of problem it makes some sense that some people see it and others can't reproduce. In that case it might be hard to figure out what caused the initial corruption. (In reply to comment #1) > $export NSPR_LOG_MODULES=all:5 That's not terribly useful. That will include all debugging output from every part of the product and what we're looking for will be painful to pick out from the noise. If possible it's better to turn on logging for the most narrow set of modules.
(In reply to comment #8) > The initial reporter also sees a problem with Chromium which has nothing in > common with Firefox, so that might be a system issue. I did more tests on chromium, and cant reproce as easy as FF. From what I can see, what I was seeing in chromium was mostly related to the change Google as been dealing with cookies and sessions on their site, ie, expiring after two weeks, for security reasons.
(In reply to comment #8) > Comment 7 is seeing it with all sites, earlier commenters only on some. We do > know in the past that corruption in the cookies.sqlite file sometimes resulted > in the inability to save any cookies. If it's that kind of problem it makes > some sense that some people see it and others can't reproduce. In that case it > might be hard to figure out what caused the initial corruption. Recreating cookies.sqlite for an existing profile and using a new profile did not solve the problem. The cookies are listed in the cookie manager. Please let me know if/how I can provide (more) useful information on this issue.
In addition to http://livejournal.com, I'm also losing cookies from http://boards.theforce.net After logging in, I can go to the cookies GUI and it looks like they have proper expiration dates. However, when I restart, the cookies are gone. Also, after closing Firefox and checking the contents of the cookies.sqlite, it looks like some of the cookies from these sites are not being written to it. So this appears to backup sdwilsh in Comment 4.
I can reproduce the issue on all sites, i.e. I have to login again and again after each browser restart, it seems not to be a site-specific issue.
I'd like to add, i'm seeing this issue with the minefield nightly also. Over the last week or two, i lose sessions on seemingly random sites after a restart. I cannot detect any noticeable pattern to it, and it affects all types of sites including Facebook,Reddit,assorted Vbulletin forums,phpBB boards,Google and Windows live etc. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100409 Minefield/3.7a5pre ID:20100409040127
I've heard multiple reports of what Rob's saying in comment 13. There have been no changes in cookie code recently. This is probably a bug in either storage, or sessionstore. sdwilsh, zpao, have there been any changes there recently?
Bug 536978 looks to be the most recent changes to the cookies service, and it's within the regression range I found. Would it be possible to get a tryserver build with Bug 536978 backed out? I'm curious to see if that will help anyone.
Builds are here: https://build.mozilla.org/tryserver-builds/dwitte@mozilla.com-try-0a84351b59b5/ I didn't think that change could be responsible since people have been seeing this just over the last week or so, but maybe it is!
Forgive my ignorance here, is this a build i can test over a few days? I assume it won't just update and overwrite the test build when a new nightly is out? Happy to run it and report back if so. Thanks.
After some preliminary testing (login to problem sites, restart a few times), the tryserver build looks to have fixed the problem I was having.
(In reply to comment #17) > Forgive my ignorance here, is this a build i can test over a few days? Correct.
The tryserver build appears to have fixed the issue. 48 hours of average use, and still holding the sessions on all my regular sites after multiple restarts.
Same here, the problem is no longer reproducible.
Shawn, can you debug and see if you can reproduce this?
(In reply to comment #21) > Same here, the problem is no longer reproducible. Being more precise, re-starting the browser does no longer cause a loss of session data, however, updating and re-starting the browser has still the same effect.
AFAIK the hourly/tryserver builds are on the nightly channel, so updating the browser will just update you to a version that has the bug.
(In reply to comment #24) > AFAIK the hourly/tryserver builds are on the nightly channel, so updating the > browser will just update you to a version that has the bug. Thanks for your clarification, with Dan Witte's trybuild, the above-described problem is indeed no longer reproducible.
Blocks: 536978
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → Trunk
Assignee: nobody → sdwilsh
I'm having a very hard time reproducing this (as in, I can't). Can somebody provide me with steps to reproduce? I can't fix this without them.
I updated back to the trunk last night after running the tryserver build for 5 days without any issues, but..... So far, the nightly seems to be free of this problem now. Is it possible something was modified over the last 4 or 5 days on the trunk build to affect this issue? Previously, the steps to reproduce were.. Tick 'remember me' & log in to a website or forum. Close tabs. Restart minefield, & upon revisiting previous website/forum you will have to log in again approx 7 out of 10 attempts at recreating the issue.
STR: 1. Create new profile 2. Login to problematic site (remember to check 'remember me' or 'auto login') 3. Restart Firefox 4. Visit site from #2 The problem is that this seems to be affecting people differently. For me this only seems to affect http://livejournal.com and http://boards.theforce.net but others see it on different/all sites. @Rob, still seeing problems on trunk.
Ok, Upon restarting the trunk from a fresh boot this morning, it appears to have lost sessions on all my common sites...phpBB,Vbulletin,IPB,gmail etc... Please disregard my previous comment.
The problem is still reproducible, i.e. sessions are lost after restart.
This issue rectified itself about 2 weeks back, for me at least. Sessions are now held.
I'm going to post a tryserver build sometime soon, with extra logging, for those willing to test. Hopefully that'll give some more info.
Found two problems by code inspection: a) BindParameters is never called in AddCookieToList: http://mxr.mozilla.org/mozilla-central/source/netwerk/cookie/src/nsCookieService.cpp#2920 b) In AddInternal, we can call RemoveCookieFromList followed by AddCookieToList. The former is unbatched, the latter is. Which means operations can get out-of-order. I'm not sure if these are resulting in the problems here, but we can fix and test.
Assignee: sdwilsh → dwitte
Attachment #445996 - Flags: review?(sdwilsh)
Attachment #445997 - Flags: review?(sdwilsh)
Comment on attachment 445996 [details] [diff] [review] Part 1: Fix AddCookieToList Ugh. I looked at this method for a good half hour when I was looking at this and didn't spot this. Can we write a test that would have caught this by chance? r=sdwilsh
Attachment #445996 - Flags: review?(sdwilsh) → review+
Comment on attachment 445997 [details] [diff] [review] Part 2: Don't batch in AddInternal r=sdwilsh
Attachment #445997 - Flags: review?(sdwilsh) → review+
Comment on attachment 445996 [details] [diff] [review] Part 1: Fix AddCookieToList http://hg.mozilla.org/mozilla-central/rev/f318846e8ee3 Should be in last night's nightly; I'll push the second part today. (Want to have separation here, for debugging purposes.)
Comment on attachment 445997 [details] [diff] [review] Part 2: Don't batch in AddInternal http://hg.mozilla.org/mozilla-central/rev/5e3a1f437674 Which will be in today's nightly.
Martin, Rob: Could you guys test with tonight's nightly? (So, download/update tomorrow, and you should get it.) If you've been having this problem recently, and it goes away with the new nightly, then I think we've fixed this one.
Looks fixed to me. The sites that were giving me problems no longer are.
Awesome. Please reopen if you see any more problems.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: