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

Status: NEW

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

Description

[Randell Jesup [:jesup] (needinfo me)]

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 cnn.com.

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

Comment 1

[Jens Stutte [:jstutte]]

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

Comment 2

[Jens Stutte [:jstutte]]

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.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 5

[Kagami Rosylight [:saschanaz] (they/them)]

S3 since it affects only debug build

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Pernosco session: https://pernos.co/debug/sIbRd7Sb13JcM7Yr1xdhhQ/index.html

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

Comment 7

[Jens Stutte [:jstutte]]

There is also bug 1585978 that might be related here.

Comment 8

[Jari Jalkanen]

Steps to reproduce:

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

Next time, when the user navigates to the clixo.com 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 .

Comment 9

[Jari Jalkanen]

Attachment: Bug 1749007 - Ignore cached usage when value is out of sync. r=#dom-storage-reviewers

Comment 11

[Jan Varga [:janv]]

We should re-test this after landing of D138636.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

Hit this again loading CNN in a debug build

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 14

[Jari Jalkanen]

With the current debug build, I cannot reproduce this one with the clixo.com 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?

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

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)

Comment 17

[Kagami Rosylight [:saschanaz] (they/them)]

Bug 1834431 looks related to the CompressionStream debug crash.

Comment 18

[Gian-Carlo Pascutto [:gcp]]

I'm hitting this reproducibly, will try to get a Pernosco trace. It's blocking me from debugging an S2.

#01: mozilla::dom::(anonymous namespace)::PrepareDatastoreOp::GetResponse(mozilla::dom::LSRequestResponse&) (/home/morbo/hg/firefox/dom/localstorage/ActorsParent.cpp:7391)
#02: mozilla::dom::(anonymous namespace)::LSRequestBase::Run() (/home/morbo/hg/firefox/dom/localstorage/ActorsParent.cpp:6418)
#03: mozilla::dom::(anonymous namespace)::LSRequestBase::Finish() (/home/morbo/hg/firefox/dom/localstorage/ActorsParent.cpp:6349)
#04: {virtual override thunk({offset(-64)}, mozilla::dom::(anonymous namespace)::LSRequestBase::RecvFinish())} (/home/morbo/hg/firefox/dom/localstorage/ActorsParent.cpp:0)
#05: mozilla::dom::PBackgroundLSRequestParent::OnMessageReceived(IPC::Message const&) (/home/morbo/hg/firefox/obj-x86_64-pc-linux-gnu/ipc/ipdl/PBackgroundLSRequestParent.cpp:197)
#06: mozilla::ipc::PBackgroundParent::OnMessageReceived(IPC::Message const&) (/home/morbo/hg/firefox/obj-x86_64-pc-linux-gnu/ipc/ipdl/PBackgroundParent.cpp:2276)
#07: mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) (/home/morbo/hg/firefox/ipc/glue/MessageChannel.cpp:1820)
#08: mozilla::ipc::MessageChannel::DispatchMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >) (/home/morbo/hg/firefox/ipc/glue/MessageChannel.cpp:0)
#09: mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::ipc::MessageChannel::MessageTask&) (/home/morbo/hg/firefox/ipc/glue/MessageChannel.cpp:1530)
#10: mozilla::ipc::MessageChannel::MessageTask::Run() (/home/morbo/hg/firefox/ipc/glue/MessageChannel.cpp:1639)
#11: nsThread::ProcessNextEvent(bool, bool*) (/home/morbo/hg/firefox/xpcom/threads/nsThread.cpp:1199)
#12: NS_ProcessNextEvent(nsIThread*, bool) (/home/morbo/hg/firefox/xpcom/threads/nsThreadUtils.cpp:480)
#13: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) (/home/morbo/hg/firefox/ipc/glue/MessagePump.cpp:0)
#14: MessageLoop::Run() (/home/morbo/hg/firefox/ipc/chromium/src/base/message_loop.cc:346)
#15: nsThread::ThreadFunc(void*) (/home/morbo/hg/firefox/xpcom/threads/nsThread.cpp:372)
#16: _pt_root (/home/morbo/hg/firefox/nsprpub/pr/src/pthreads/ptthread.c:204)
#17: set_alt_signal_stack_and_start(PthreadCreateParams*) (/home/morbo/hg/firefox/mozglue/interposers/pthread_create_interposer.cpp:81)
#18: ??? (/lib/x86_64-linux-gnu/libc.so.6 + 0x94ac3)
#19: ??? (/lib/x86_64-linux-gnu/libc.so.6 + 0x126850)
#20: ??? (???:???)

Program /home/morbo/hg/firefox/obj-x86_64-pc-linux-gnu/dist/bin/firefox (pid = 691429) received signal 11.
Stack:
#01: nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) (/home/morbo/hg/firefox/toolkit/profile/nsProfileLock.cpp:188)
#02: WasmTrapHandler(int, siginfo_t*, void*) (/home/morbo/hg/firefox/js/src/wasm/WasmSignalHandlers.cpp:0)
#03: ??? (/lib/x86_64-linux-gnu/libc.so.6 + 0x42520)
#04: mozilla::dom::(anonymous namespace)::PrepareDatastoreOp::GetResponse(mozilla::dom::LSRequestResponse&) (/home/morbo/hg/firefox/dom/localstorage/ActorsParent.cpp:7391)
#05: mozilla::dom::(anonymous namespace)::LSRequestBase::Run() (/home/morbo/hg/firefox/dom/localstorage/ActorsParent.cpp:6418)
#06: mozilla::dom::(anonymous namespace)::LSRequestBase::Finish() (/home/morbo/hg/firefox/dom/localstorage/ActorsParent.cpp:6349)
#07: {virtual override thunk({offset(-64)}, mozilla::dom::(anonymous namespace)::LSRequestBase::RecvFinish())} (/home/morbo/hg/firefox/dom/localstorage/ActorsParent.cpp:0)
#08: mozilla::dom::PBackgroundLSRequestParent::OnMessageReceived(IPC::Message const&) (/home/morbo/hg/firefox/obj-x86_64-pc-linux-gnu/ipc/ipdl/PBackgroundLSRequestParent.cpp:197)
#09: mozilla::ipc::PBackgroundParent::OnMessageReceived(IPC::Message const&) (/home/morbo/hg/firefox/obj-x86_64-pc-linux-gnu/ipc/ipdl/PBackgroundParent.cpp:2276)
#10: mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) (/home/morbo/hg/firefox/ipc/glue/MessageChannel.cpp:1820)
#11: mozilla::ipc::MessageChannel::DispatchMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >) (/home/morbo/hg/firefox/ipc/glue/MessageChannel.cpp:0)
#12: mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::ipc::MessageChannel::MessageTask&) (/home/morbo/hg/firefox/ipc/glue/MessageChannel.cpp:1530)
#13: mozilla::ipc::MessageChannel::MessageTask::Run() (/home/morbo/hg/firefox/ipc/glue/MessageChannel.cpp:1639)
#14: nsThread::ProcessNextEvent(bool, bool*) (/home/morbo/hg/firefox/xpcom/threads/nsThread.cpp:1199)
#15: NS_ProcessNextEvent(nsIThread*, bool) (/home/morbo/hg/firefox/xpcom/threads/nsThreadUtils.cpp:480)
#16: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) (/home/morbo/hg/firefox/ipc/glue/MessagePump.cpp:0)
#17: MessageLoop::Run() (/home/morbo/hg/firefox/ipc/chromium/src/base/message_loop.cc:346)
#18: nsThread::ThreadFunc(void*) (/home/morbo/hg/firefox/xpcom/threads/nsThread.cpp:372)
#19: _pt_root (/home/morbo/hg/firefox/nsprpub/pr/src/pthreads/ptthread.c:204)
#20: set_alt_signal_stack_and_start(PthreadCreateParams*) (/home/morbo/hg/firefox/mozglue/interposers/pthread_create_interposer.cpp:81)
#21: ??? (/lib/x86_64-linux-gnu/libc.so.6 + 0x94ac3)
#22: ??? (/lib/x86_64-linux-gnu/libc.so.6 + 0x126850)
#23: ??? (???:???)

Comment 20

[Jan Varga [:janv]]

It seems this is related to the usage file which contains cached usage information. We can get rid of the usage file once we have async temp storage init.

Comment 21

[Jens Stutte [:jstutte]]

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

It seems this is related to the usage file which contains cached usage information. We can get rid of the usage file once we have async temp storage init.

Yeah, from the (private) pernosco session it seems that both the usage file and the DB we read the check value from existed before starting the browser and were not altered during the session. So whatever made them diverge happened earlier. Getting rid of the usage file is probably our best and easiest option then.