1630403 - Crash in [@ IPCError-browser | ShutDownKill | internal_fallocate]

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P3)

Description

[Chris Peterson [:cpeterson]]

This bug is for crash report bp-63a264ce-7832-4bce-a1bb-3c3b20200415.

There is a new Linux-only ShutdownKill crash signature with "Crash Reason: DUMP_REQUESTED" from just two installations on one person's machine. 100% of the 93 crash reports have Fission enabled.

Top 10 frames of crashing thread:

0 libc.so.6 internal_fallocate /usr/src/debug/glibc-2.31/io/../sysdeps/posix/posix_fallocate.c:32
1 libxul.so PollWrapper widget/gtk/nsAppShell.cpp:59
2 libglib-2.0.so.0 g_main_context_iterate ../glib/gmain.c:4042
3 libglib-2.0.so.0 <name omitted> ../glib/gmain.c:4108
4 libxul.so nsAppShell::ProcessNextNativeEvent widget/gtk/nsAppShell.cpp:275
5 libxul.so <name omitted> widget/nsBaseAppShell.cpp:259
6 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1104
7 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:109
8 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
9 libxul.so nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137

Comment 1

[Chris Peterson [:cpeterson]]

:gsvelto says:

[This is] a valid ShutDownKill but the signature is new, because it's from a Fedora-packaged build of Firefox for which symbols were added only recently.

One interesting bit is that none of the crash reports has the IPCShutdownState annotation set which means that none of those processes received the IPC shutdown message. And there's another interesting tidbit: the uptime is often very low, just a few secs often times.

it might be a symptom for a larger problem. A quick search for ShutDownKill crashes with Fission enabled shows the vast majority of them having very short uptime and no IPCShutdownState annotation: https://crash-stats.mozilla.org/search/?signature=~ShutDownKill&dom_fission_enabled=%21__null__&uptime=%3C15&date=%3E%3D2020-04-08T20%3A40%3A00.000Z&date=%3C2020-04-15T20%3A40%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Those are content processes which have had barely the time to startup and never received a shutdown message, maybe there's some race somewhere preventing them from receiving it or mis-handling it.

Could those short-lived process crashes be related to the problem we saw a few weeks ago where new content processes were mysteriously and silently failing the launch (bug 1618936)?

Comment 2

[Chris Peterson [:cpeterson]]

kmag recommends we wait for Randell's work on process pre-allocation before spending much time debugging Fission ShutdownKills.

P5 Future

Comment 3

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

These are current, open bugs with a Severity of critical. The Severity of these bugs is being changed to S2 to be consistent with the May 4 2020 Severity definitions.

Please let Release Management know if these bugs are still S2.

Comment 4

[Pascal Chevrel:pascalc (PTO until April 26)]

Chris is this bug an S2?

Comment 5

[Chris Peterson [:cpeterson]]

(In reply to Pascal Chevrel:pascalc from comment #4)

Chris is this bug an S2?

I'll reduce this bug's severity to S3 because it is low volume (after an initial spike) and only appears to affect Nightly users.

Comment 6

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

Closing because no crashes reported for 12 weeks.