443011 - cookies not working after a crash

Status: RESOLVED WORKSFORME

(Core :: Networking: Cookies, defect)

Description

[Alessandro]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9) Gecko/2008061004 Firefox/3.0

When Firefox 3 crashes, the cookies database seems to corrupt irreversibly.
Not only existing cookies seems to be deleted, but if you create new ones and then close the browser, those are deleted after browser closes.
After this, to make cookies work again you must delete the cookies.sqlite file in your profile.

Reproducible: Always

Steps to Reproduce:
1. make firefox 3 crash (in some way). then reopen it using "restore session" (I've always done this: don't know if closing firefox completely resolves the problem)
2. try to visit a site which use cookies to remember login. you will need to login again.
3. when logging in, use the "remember login" feature
4. close firefox, reopen it and visit that site again: you will need to login again
Actual Results:  
cookies are deleted

Expected Results:  
cookies should stay

Comment 1

[Asa Dotzler [:asa]]

This is being reported quite a bit in blogs and twitter. The symptoms are most often reported as "sites don't save my login information" and deleting cookies.sqlite solves the problem.

I believe this is one of the highest profile issues for Firefox 3.0 and 3.0.1 that I'm seeing reported "out on the web"

Comment 2

[Asa Dotzler [:asa]]

(this issue is not to be confused with the Firefox TOR extension hosing cookies for all of its users.)

Also, I've crashed and don't see it so the steps to reproduce above are not 100% but it does appear that crashing has been at least one of the reasons for cookies.sqlite to break. 

Comment 3

[Alessandro]

Additional info:
the problem happened with a profile after upgrade Firefox 2 -> Firefox 3.
I've deleted the profile and created a new one: now Firefox doesn't crash as often as before (when also a flash movie caused a crash), and I've not seen cookies reset.

BTW, in the old profile I had the TOR button (even if I didn't use it so much).

Comment 4

[Daniel Veditz [:dveditz]]

Hm, I think I'm experiencing this myself. I leave the browser up for a long time (days, easily a week if I don't crash) so I'm not entirely sure, but I've been annoyed that bugzilla has lost my column selections several times. I'd be happy to send my cookies.sqlite to dwitte or another developer fixing this problem (not so much attaching it to the bug, though).

I've never installed Tor on my Mac profile where I've experienced the problem. I do have Web Developer 1.1.6 and View Cookies 1.7 which have cookie-related functionality but don't seem likely culprits.

Comment 5

[benc]

So, is there a belief that the profile migration is related? I haven't seen this myself, but I am running FF3 on an upgraded FF2 profile. What symptoms should I look for? (I also switch back and forth, w/o knowing if this is bad for my profile :))

Comment 6

[Alessandro]

well, in my experience, an upgraded profile crashes very frequently (in particular, I experienced crash when loading a web page using Flash movies), and after the crash cookies are deleted.

in my old profile I had installed many extensions. I can't remember all, but this list should be quite complete:
- TOR button
- Chris Pedrick's web developer toolbar and user agent switcher
- Firebug
- Greasemonkey
- Colorzilla
- Stylish
- Gmail Notifier
- Google Reader Notifier
I was on Mac OSX.

By the way, I remember I had to start with a new profile when I had upgraded from Firefox 1.5 to Firefox 2.

Comment 7

[[e-mail]]

(In reply to comment #4)
> Hm, I think I'm experiencing this myself. I leave the browser up for a long
> time (days, easily a week if I don't crash) so I'm not entirely sure, but I've
> been annoyed that bugzilla has lost my column selections several times. I'd be

does it lose them mid-session, or on crash/startup, or or...? if mid-session, it could be the "cookies eagerly evicted" bug which mconnor has been chasing recently (his theory is that session cookies, which sessionstore saves, are ousting other cookies).

if on crash, that's likely something else, which i'll assume this bug is about :)

(In reply to comment #5)
> So, is there a belief that the profile migration is related? I haven't seen
> this myself, but I am running FF3 on an upgraded FF2 profile. What symptoms
> should I look for? (I also switch back and forth, w/o knowing if this is bad
> for my profile :))

cookies.sqlite is generated when you first migrate a profile (on startup), at which time cookies.txt is deleted. running an older firefox will generate a new cookies.txt, but firefox 3 will ignore it since cookies.sqlite already exists. so i'd be surprised if this is migration related.

it seems that what this bug is about is something failing in nsCookieService::InitDB, which prevents the sqlite db from being opened.

http://mxr.mozilla.org/seamonkey/source/netwerk/cookie/src/nsCookieService.cpp#469

based on comment 0, if it were detectable corruption, the file would be deleted and created afresh - but it sounds like it remains there, without being touched, and new cookies aren't written out. that'd be consistent with a general failure in InitDB(), such as the db failing to open (possibly an already-open filehandle?), failing to create the table (unlikely since this is an already-existing db), something relating to schema upgrading (unlikely since this, i presume, is on a profile that's been in use with ff 3.0.0 for some time), Read() failing (only plausible way is for one of the bind or execute steps to fail).

narrowing that list down (cookie logging will help a bit) would be a good start... running a debug build on a profile where the cookie file isn't read in properly would be ideal.

Comment 8

[Shawn Wilsher :sdwilsh]

The db is run with PRAGMA synchronous = OFF, which could lead to corruption if the application crashes.

Comment 9

[Alessandro]

(In reply to comment #7)
> does it lose them mid-session, or on crash/startup, or or...? if mid-session,
> it could be the "cookies eagerly evicted" bug which mconnor has been chasing
> recently (his theory is that session cookies, which sessionstore saves, are
> ousting other cookies).
> 
> if on crash, that's likely something else, which i'll assume this bug is about
> :)
In my experience, cookies are kept correctly during the session.
But, after the database has corrupted, all the cookies are deleted when closing the browser (or when opening it again?).

I think I *might* have my old profile... Would it be useful if I post it here? (of course, with all my personal information removed)

Comment 10

[[e-mail]]

we need async api love (combined with an integrity check on startup, perhaps) to mitigate this.

Comment 11

[Samuel Sidler (old account; do not CC)]

Won't block on this with no patch, tests, or owner. We want this though, who can own it?

Comment 12

[Shawn Wilsher :sdwilsh]

Given the dependency on bug 449990, this won't ever make it to branch.

Comment 13

[[e-mail]]

bug 448372 will help just a little here, by making "remove all cookies" nuke the db if it's corrupt (though that still requires user action).

Comment 14

[Samuel Sidler (old account; do not CC)]

Sounds good to me.

Comment 15

[Richard Cook]

Please fix this as soon as humanly possible. It's killing me. I'm getting old. I can't remember all my logins for sites...

Thanks,
Rich

Comment 16

[Wayne Mery (:wsmwk)]

~don't think i've ever seen this. and I crash a lot.

Comment 17

[Richard Cook]

I've not seen this bug in the latest releases...I did 4 years ago...

Comment 18

[Wayne Mery (:wsmwk)]

Thanks Richard