Crash report: https://crash-stats.mozilla.org/report/index/e33cc6de-e9ff-4f2f-a59e-08b270210626

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(params.mBrokerFd >= 0)

Top 10 frames of crashing thread:

0 libxul.so mozilla::ContentProcessSandboxParams::ForThisProcess security/sandbox/linux/glue/SandboxPrefBridge.cpp:28
1 libxul.so mozilla::dom::ContentChild::RecvSetProcessSandbox dom/ipc/ContentChild.cpp:1685
2 libxul.so mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:8940
3 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2012
4 libxul.so mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:805
5 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1152
6 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
7 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
8 libxul.so nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
9 libxul.so XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp:910

This appears to be a Linux-specific assertion that started triggering more frequently on nightly with buildid 20210625093436. We have three crashes on record prior to that but it's hard to tell if they were spurious or are the same problem given that the volume only picked up after that build.

fd exhaustion could cause this — maybe at this point in the child process, but more likely this dup in the parent process which is checked only with a debug assertion.

Also… unless I'm missing something, that looks like a file descriptor leak. Which might be the reason we've been seeing more fd exhaustion on Linux lately. I'll file a separate bug for that.

Changing severity to S3 because of very low crash volume.