Open Bug 1749007 Opened 2 years ago Updated 7 months ago

Frequent MOZ_ASSERT(mUsage == mDEBUGUsage) at dom/localstorage/ActorsParent.cpp:7327


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





(Reporter: jesup, Unassigned)




(1 obsolete file)

I've been getting occasional crashes from
MOZ_ASSERT(mUsage == mDEBUGUsage) at dom/localstorage/ActorsParent.cpp:7327
when starting debug builds, and also recently it's been crashing on that everytime I try to load

Linux, local debug+opt build. With some patches for a few locking issues around the tree; nothing that should impact anything significant.

Hi, can you reproduce this easily enough up to the point of getting a pernosco trace?

Flags: needinfo?(rjesup)

Hmm, looking at the code I suspect that the interesting moment in time was when we wrote/corrupted some data on disk that then does not match our debug counting. So probably a pernosco session of the assert will not reveal much, but I might be wrong.

I suspect I can reproduce with, yes. I just need to remember the options for recording a trace for pernosco...

Flags: needinfo?(rjesup)

alias pernosco-record 'rr record -M --disable-cpuid-features-ext 0xdc230000,0x00002c42,0x0000000c'

S3 since it affects only debug build

Severity: -- → S3
Priority: -- → P3

Pernosco session:

Still insta-crash with cnn. This also means the code pathways aren't getting hit in our tests.

See Also: → 1747894

There is also bug 1585978 that might be related here.

Steps to reproduce:

  1. Navigate to and then to shop and to a product page
  2. Create a new tab to the same window
  3. Go back to tab and add a product to the cart
  4. Quickly close the tab

Next time, when the user navigates to the tab or reopens the browser, the initial mUsage coming from the depths of the quota manager and mDEBUGUsage which is the actual sum of the key + value UTF16 lengths which were found from the database, will disagree.

I managed to get both cases mUsage > mDEBUGUsage and mUsage < mDEBUGUsage .

Assignee: nobody → jjalkanen

We should re-test this after landing of D138636.

Attachment #9261876 - Attachment is obsolete: true

Hit this again loading CNN in a debug build

Flags: needinfo?(jjalkanen)

And I've hit it twice in a row there now.
(gdb) p mUsage
$1 = 237303
(gdb) p mDEBUGUsage
$2 = 230774

With the current debug build, I cannot reproduce this one with the steps above.

However, following the steps causes the tab to crash for a different reason. It impacts only the content process. This should probably be filed as a separate issue.

But is the original limitation still reproducible?

Flags: needinfo?(rjesup)
Flags: needinfo?(krosylight)
Flags: needinfo?(jjalkanen)

I loaded a few pages on CNN, and no crashes, but it was never a perma-crash on CNN in debug builds; it would crash sometimes.

Flags: needinfo?(rjesup)

I can't repro the CompressionStream assertion failure on clixo, how consistently can you repro that? And could you file a new bug for that with more detailed repro? (Click-this-and-this style rather than do-this one)

Flags: needinfo?(krosylight) → needinfo?(jjalkanen)

Bug 1834431 looks related to the CompressionStream debug crash.

Flags: needinfo?(jjalkanen)
Assignee: jjalkanen → nobody
You need to log in before you can comment on or make changes to this bug.