Closed Bug 1566896 Opened 1 year ago Closed 1 year ago

Crash in [@ OOM | large | NS_ABORT_OOM | nsTSubstring<T>::SetLength]

Categories

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

Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox69 --- wontfix
firefox70 --- fixed
firefox71 --- fixed

People

(Reporter: marcia, Assigned: janv)

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-4ceca224-3ad1-476f-b527-571880190717.

Discussed during platform triage. This is the #19 overall top crash currently on 68: https://bit.ly/2LWm2mY. There was work done in Bug 1508740, but I am not entirely clear if these are remaining crashes that we are living with and if this is the best we can do. ni on :jvarga since he has some final comments in the bug. Also if this needs to move product component, please do so - I was just trying to keep this bug focused on the Fennec specific crashes in 68.

In 67 release we had 8,805 crashes
In 68 release so far we have 1,044

(100.0% in signature vs 06.74% overall) moz_crash_reason = MOZ_CRASH(OOM)
(70.59% in signature vs 11.48% overall) Module "AudioFlinger::Client (deleted)" = true
(100.0% in signature vs 45.98% overall) Module "startupCache.4.little" = true
(100.0% in signature vs 46.82% overall) address = 0x0
(100.0% in signature vs 52.93% overall) Module "linker" = true

Top 10 frames of crashing thread:

0 libxul.so NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:604
1 libxul.so nsTSubstring<char16_t>::SetLength xpcom/string/nsTSubstring.cpp:940
2 libxul.so IPC::ParamTraits<nsTSubstring<char16_t> >::Read ipc/glue/IPCMessageUtils.h:427
3 libxul.so mozilla::dom::PBackgroundStorageParent::OnMessageReceived ipc/ipdl/PBackgroundStorageParent.cpp:457
4 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2151
5 libxul.so mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1968
6 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1175
7 libxul.so NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
8 libxul.so mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:333
9 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290

Flags: needinfo?(jvarga)

Julien, this crash is mentioned in bug 1508740 - is there followup work that needs to be done? The crash rate on Fennec is lowish, around 200/day, do you think you will spend more time on this or should we accept this for now?

Marked as a P5 but can move to higher priority if the crash rate changes.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(jcristau)
Resolution: --- → FIXED
Priority: -- → P5

I'm not sure why you're asking me?

AFAICT we're getting closer to 400 fennec crashes / day from this signature, putting it at the #15 spot, which is not really good...

Flags: needinfo?(jcristau) → needinfo?(sarentz)

Let's try DOM: Web Storage due to the presence of |libxul.so mozilla::dom::PBackgroundStorageParent::OnMessageReceived ipc/ipdl/PBackgroundStorageParent.cpp:457" on the stack.

Component: General → DOM: Web Storage
Flags: needinfo?(sarentz)
Product: Firefox for Android → Core

I'm going to assume that Stefan didn't mean to close this.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Hsin-Yi, can you help find someone to investigate the desktop crashes? The volume in beta 70 is high.

Flags: needinfo?(htsai)
Priority: P5 → P1

Here are some correlations for Desktop 70 beta:

OOM | large | NS_ABORT_OOM | nsTSubstring<T>::SetLength signature in 70 beta has average between 130-219 crashes per beta. Here are the correlations:

(100.0% in signature vs 05.27% overall) moz_crash_reason = MOZ_CRASH(OOM)
(100.0% in signature vs 38.38% overall) abort_message = null
(87.56% in signature vs 22.73% overall) Module "MP3DMOD.DLL" = true [87.35% vs 29.44% if platform_pretty_version = Windows 7]
(100.0% in signature vs 54.85% overall) reason = EXCEPTION_BREAKPOINT
(72.89% in signature vs 36.47% overall) Module "msmpeg2adec.dll" = true [99.03% vs 58.43% if platform_version = 6.1.7601 Service Pack 1]
(32.00% in signature vs 100.0% overall) e10s_cohort = null [28.89% vs 69.23% if process_type = content]
(28.89% in signature vs 68.25% overall) app_init_dlls = null
(32.00% in signature vs 69.90% overall) plugin_version = null
(68.00% in signature vs 30.42% overall) ipc_fatal_error_msg = null
(98.67% in signature vs 61.09% overall) Module "evr.dll" = true [99.03% vs 66.25% if platform_version = 6.1.7601 Service Pack 1]
(76.44% in signature vs 42.46% overall) Module "ksuser.dll" = true [99.03% vs 66.49% if platform_version = 6.1.7601 Service Pack 1]
(73.33% in signature vs 41.07% overall) Module "atl.dll" = true [99.40% vs 67.88% if platform_pretty_version = Windows 7]
(98.67% in signature vs 61.69% overall) Module "mozavutil.dll" = true [99.40% vs 68.31% if platform_pretty_version = Windows 7]
(98.67% in signature vs 61.69% overall) Module "mozavcodec.dll" = true [99.40% vs 68.31% if platform_pretty_version = Windows 7]

The fix in bug 1576260 should help lower down the number of crashes in this bug too.

Flags: needinfo?(jvarga)

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

The fix in bug 1576260 should help lower down the number of crashes in this bug too.

Thanks Jan!

(In reply to Liz Henry (:lizzard) from comment #5)

Hsin-Yi, can you help find someone to investigate the desktop crashes? The volume in beta 70 is high.

Looks Jan is on top of it. :)

Flags: needinfo?(htsai)
Assignee: nobody → jvarga

Nightly looks good, no crashes recently. Beta 8 (with the fix) went out just yesterday, it's too early to judge if it's fixed there too.

Fixed by patch in bug 1576260.

Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED

Is there anything we can do to improve things for Fennec on ESR68 here? We've got over 3000 reports from 68.1.1 at this point.

Flags: needinfo?(jvarga)

We could try to do something in the old LS implementation, but I don't think we have resources for that right now. We are focusing on fixing storage initialization failures that prevent LSNG from being enabled on release.

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