Open Bug 1591877 Opened 3 months ago Updated 9 days ago

Crash in [@ InvalidArrayIndex_CRASH | mozilla::dom::quota::QuotaManager::GetUsageForClient]

Categories

(Core :: Storage: Quota Manager, defect, P2, critical)

Unspecified
Linux
defect

Tracking

()

People

(Reporter: gsvelto, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-15409535-80bd-4247-bdbc-11f7c0191027.

Top 10 frames of crashing thread:

0 libxul.so InvalidArrayIndex_CRASH xpcom/ds/nsTArray.cpp:27
1 libxul.so mozilla::dom::quota::QuotaManager::GetUsageForClient dom/quota/ActorsParent.cpp:4139
2 libxul.so mozilla::dom:: dom/localstorage/ActorsParent.cpp:7807
3 libxul.so mozilla::dom:: dom/localstorage/ActorsParent.cpp:6726
4 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1225
5 libxul.so <name omitted> xpcom/threads/nsThreadUtils.cpp:486
6 libxul.so mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:303
7 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
8 libxul.so nsThread::ThreadFunc xpcom/threads/nsThread.cpp:458
9 libnspr4.so _pt_root nsprpub/pr/src/pthreads/ptthread.c:201

The raw crash reason is ElementAt(aIndex = 3, aLength = 3).

The unwinding hides the real line where we're crashing, looking at the frames it appears to be this one:

https://searchfox.org/mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212/dom/quota/ActorsParent.cpp#7891

Assignee: nobody → jvarga
Status: NEW → ASSIGNED
Priority: -- → P2
Assignee: jvarga → nobody
Status: ASSIGNED → NEW

So OriginInfo contains ClientUsageArray mClientUsages;, which is initialized to have length:

  static Type TypeMax() {
    if (CachedNextGenLocalStorageEnabled()) {
      return TYPE_MAX;
    }
    return LS;
  }

and never touched afterwards in terms of length until destruction. I see two possible reasons:

  1. We changed the pref driving CachedNextGenLocalStorageEnabled() during runtime to false, creating thus smaller mClientUsages but somewhere in our code we still expect to have the longer variant. In any case it looks a bit odd, that the memory layout of an array of a probably serialized object depends on a pref, that might flip anytime.
  2. We try to access mClientUsages after that it has been deconstructed (which probably means, the underlying OriginInfo has been freed).
You need to log in before you can comment on or make changes to this bug.