1585978 - Used storage space for saved cookies and site data is abnormal in some circumstances

Status: NEW

(Core :: Storage: localStorage & sessionStorage, defect, P3)

Description

[Mark Banner (:standard8)]

Attachment: Screenshot 2019-10-03 at 13.21.40.png

I'm on Mac, using the latest nightly build. I was investigating another bug at the time, here's roughly what I did:

• Used Time Machine to restore my main profile from a previous day to a new directory. I only restored the ~/Library/Application Support/Firefox/Profiles/<profile folder> section, not the cache.
• Added the new profile directory to profiles.ini
• Started Firefox with the new profile.

When I went into preferences, at some stage, I noticed that the cookies and site data were on about 17 exabytes. This was obviously not quite right.

I later restarted and it then showed a reasonable 189MB.

Comment 1

[:Gijs (he/him)]

FWIW, integer overflow of -1 for 64-bit is apparently 18,446,744,073,709,551,615 , which if divided by 1024 * 1024 * 1024 (from bytes to gb) is that number. So I suspect that's what's going on... somewhere.

Comment 2

[Andrew Overholt [:overholt]]

(In reply to :Gijs (he/him) from comment #1)

FWIW, integer overflow of -1 for 64-bit is apparently 18,446,744,073,709,551,615 , which if divided by 1024 * 1024 * 1024 (from bytes to gb) is that number. So I suspect that's what's going on... somewhere.

Jan Varga said the same thing :) He might have an idea of what can cause this.

Comment 3

[Jan Varga [:janv]]

Yeah, I'll try to fix this before enabling LSNG on release.

Comment 6

[Honza Bambas (:mayhemer)]

Just one question here: does this in any way likely affect cookies functionality somehow? I have a weird bug for instance that I'm always logged off from matrix on Nightly restart. Just checking if those can be related or not.

Comment 7

[Jan Varga [:janv]]

I don't think it's related. I suspect this is only a usage calculation problem when we end up with a negative big int which is then interpreted as insanely large positive number.

Comment 9

[:Gijs (he/him)]

(In reply to Jan Varga [:janv] from comment #7)

I don't think it's related. I suspect this is only a usage calculation problem when we end up with a negative big int which is then interpreted as insanely large positive number.

Per some of the debugging in bug 1743017 the quota usage per origin is reporting negative numbers; that seems like it could potentially mislead other code about how much space is still available for that origin?

Although it's good to have reproducible steps such as in comment 0, I can't imagine everyone seeing this has gone through the steps in that comment, there must be different ways of hitting this problem...

Comment 10

[:Gijs (he/him)]

Jens, can this be prioritized? It's causing other side effects than just "funny" numbers, cf. bug 1749985.

Comment 12

[Jens Stutte [:jstutte]]

Jan, do we have some QM_TRY in place to see these failures in order to have a feeling, how often this happens in the wild?

Comment 13

[Axel Braun]

see exactly the same issue on openSUSE Tumbleweed, FF 101.0.1
Absolut disk usage:
docb@X1E:~> du -sh .mozilla/firefox
1,6G .mozilla/firefox

I clearly did not juggle around with profiles....

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:jjalkanen, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 15

[Jari Jalkanen]

The severity S3 seems appropriate.

Comment 16

[Jan Varga [:janv]]

The code which deals with usage calculation needs to be checked if some kind of overflow can happen. For example we can get a negative overall usage which then gets converted from a signed integer to unsigned integer, resulting in reporting insane total usage.