Chrome not loading Cookies file

[Chris Masone]

Hello, folks.  I'm trying to debug a Chrome-on-Chrome-OS issue.  Browser version is 7.0.511.2, dev build 58616

  I've got a device here that logs in fine, saves a the user's browsing history fine, caches web content fine...but never saves cookies.  Looking at the files in the user's profile, "Cookies" and "Cookies-journal" haven't been touched since 9/1, though other files and dirs in the profile have been touched since then.  The user has been using the device, over the last week, so it should have been storing cookies.

I looked at the chrome logs and didn't see anything obvious about Cookies not being loaded, but I admit I don't know what I'm looking for.  Is there anything I can do to verify that the Cookies file is valid?  Or invalid?

Thanks!

cmasone

[Eric Roman]

You can start by looking at this histogram:

about:histograms/net.CookieBackingStoreUpdateResults

  0=success

  1=failure

If you see ones's then there were SQLite failures.

If you don't see any data, then a SQLite cookie backing store was never connected.

If you see all zeros then according to the code everything is working OK.

Next up, you can set set breakpoints in:

src/chrome/browser/net/sqlite_persistent_cookie_store.cc

To trace through the process and see if/when it breaks.

Lastly, note that the Cookies file is just a sqlite database.

You can dump it using the "sqlite3" command line tool.

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Peter Kasting]

It seems like sqlite has its own form of locking?  Maybe in that sense the cookie DB is "locked" (due to crash on shutdown?) and now it refuses to touch it?

PK

[Chris Masone]

I saw no histogram at all, and when I tried to load it with sqlite 3 thusly:

$ sqlite3 Cookies

sqlite> select * from sqlite_master;

I get "Error: unable to open database file"

I can look at it with cat and less, so it's not like I don't have permission to open this file...

[Scott Hess]

Locks should all be types which expire when the program crashes. So
this shouldn't happen unless you have multiple browsers running, or
imperfect locking implementations (over NFS or SMB or something).

From sqlite3, could you run "pragma integrity_check;"?

-scott

[Lei Zhang]

Does: sqlite3 "$f" "pragma integrity_check" give you can error?

On Thu, Sep 9, 2010 at 1:28 PM, Chris Masone <cma...@chromium.org> wrote:

[Chris Masone]

I get the same error: unable to open database file.

So i can be sure I'm not using sqlite3 wrong, what else is in the profile is an sqlite db that I could look at?

[Chris Masone]

ok, I looked at .pki/nssdb/cert9.db and that passed the integrity check.  So I feel confident I'm not using the tool wrong :-)

[Eric Roman]

Yep, sounds like your cookies DB is hosed.

We do have a bigger general problem which is how chrome detects, reports, and reacts to user profile corruption.

Silent chronic failures are no good.

(For this specific instance, even just having automatically recreated the cookie DB would have been preferable to ongoing failures).

[re-sent from the right address this time]

[Chris Masone]

On Thu, Sep 9, 2010 at 1:53 PM, Eric Roman <ero...@chromium.org> wrote:

Yep, sounds like your cookies DB is hosed.

We do have a bigger general problem which is how chrome detects, reports, and reacts to user profile corruption.

Silent chronic failures are no good.

(For this specific instance, even just having automatically recreated the cookie DB would have been preferable to ongoing failures).

Indeed.  I've moved the file over to my desktop, though, where I have an older version of sqlite3, and the integrity check tells me of 4 rows missing from "index sqlite_autoindex_cookies_1"

 

Is that interesting/useful?

[Scott Hess]

Hmm. Did you move just the database file, or did you also copy the
-journal file? You might just have a half-updated database file.

-scott

[PhistucK]

I know this is a ridiculous thought, but I heard it happened to someone I know - with a fresh installation of Chrome -

Did you make sure that the Content Settings are not set to not store cookies?

☆PhistucK

[Chris Masone]

On Thu, Sep 9, 2010 at 11:54 PM, PhistucK <phis...@gmail.com> wrote:

I know this is a ridiculous thought, but I heard it happened to someone I know - with a fresh installation of Chrome -

Did you make sure that the Content Settings are not set to not store cookies?

Yeah, we did.  It wasn't a fresh install; it had been storing cookies and then stopped.

It seems like the Cookies-journal file got corrupted, and that's the end of cookies :-/

[Randy Smith]

On Fri, Sep 10, 2010 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:
>
>
> On Thu, Sep 9, 2010 at 11:54 PM, PhistucK <phis...@gmail.com> wrote:
>>
>> I know this is a ridiculous thought, but I heard it happened to someone I
>> know - with a fresh installation of Chrome -
>> Did you make sure that the Content Settings are not set to not store
>> cookies?
>
> Yeah, we did.  It wasn't a fresh install; it had been storing cookies and
> then stopped.
> It seems like the Cookies-journal file got corrupted, and that's the end of
> cookies :-/

I'd love to get a better handle on *why* this sometimes happens. Was
there anything that was correlated with the corruption? An unexpected
crash or something like it?

(And yes, we should automatically detect this and move the Cookie DB
out of the way with a notification to the user. I've meant to file a
bug on that and hadn't gotten to it :-J; I'll do that now.)

We're in this tricky position with regard to DB corruption in that it
does sometimes "just happen", but it might also be some kind of bug in
the code that causes it, and we don't want to ignore that possibility
because sometimes the same problem can occur with code bugs :-J.

-- Randy

[Chris Masone]

On Fri, Sep 10, 2010 at 11:25 AM, Randy Smith <rds...@google.com> wrote:

On Fri, Sep 10, 2010 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:
>
>
> On Thu, Sep 9, 2010 at 11:54 PM, PhistucK <phis...@gmail.com> wrote:
>>
>> I know this is a ridiculous thought, but I heard it happened to someone I
>> know - with a fresh installation of Chrome -
>> Did you make sure that the Content Settings are not set to not store
>> cookies?
>
> Yeah, we did.  It wasn't a fresh install; it had been storing cookies and
> then stopped.
> It seems like the Cookies-journal file got corrupted, and that's the end of
> cookies :-/

I'd love to get a better handle on *why* this sometimes happens.  Was
there anything that was correlated with the corruption?  An unexpected
crash or something like it?

In this particular case, it's on a Chrome OS device, which has the user's profile stored in an eCryptfs-backed directory.  We discovered that the file is corrupted at the ecryptfs level, so it's unlikely to be Chrome's fault or sqlite's fault.  

[Evan Martin]

For future reference:
google-chrome --diagnostics
will run this and other tests on all databases.