Open Bug 1643016 Opened 4 years ago Updated 2 years ago

Crash in [@ mozilla::ipc::IToplevelProtocol::CreateSharedMemory]

Categories

(Core :: IPC, defect)

Unspecified
Windows 10
defect

Tracking

()

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: crash)

Crash Data

I hit this crash with a Firefox Nightly 79.0a1 build on Windows 10 while navigating between pages on Youtube. It might be related to the hangs/freezes as reported on bug 1639544.

This bug is for crash report bp-a7df3eed-20bd-4b27-8c19-a73620200603.

Top 10 frames of crashing thread:

0 xul.dll mozilla::ipc::IToplevelProtocol::CreateSharedMemory ipc/glue/ProtocolUtils.cpp:714
1 xul.dll mozilla::ipc::IProtocol::AllocUnsafeShmem ipc/glue/ProtocolUtils.cpp:413
2 xul.dll mozilla::ShmemPool::Get<mozilla::RemoteDecoderChild> dom/media/systemservices/ShmemPool.h:119
3 xul.dll mozilla::RemoteDecoderChild::Decode dom/media/ipc/RemoteDecoderChild.cpp:109
4 xul.dll mozilla::detail::ProxyFunctionRunnable<`lambda at /builds/worker/checkouts/gecko/dom/media/ipc/RemoteMediaDataDecoder.cpp:55:7', mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, 1> >::Run xpcom/threads/MozPromise.h:1540
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1211
6 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:332
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
9 xul.dll static nsThread::ThreadFunc xpcom/threads/nsThread.cpp:444

https://hg.mozilla.org/mozilla-central/file/3609aa746c291a437f02e467f94149c6fd0ddb0a/ipc/glue/ProtocolUtils.cpp#l681

The crash reason is MOZ_RELEASE_ASSERT(mLastLocalId < (1 << 29)). There are some crashes that look like this on beta, too, so maybe it isn't a new issue. I've been looking at this file so I was worried I might have cause a regression, but my patches that touch shared memory haven't landed yet.

That suggests that we've used more than 500 million shmems on the RemoteDecoderChild actor, which is a bit concerning.

CC'ing dminor, since I think he's been looking at the remote decoder most recently.

Flags: needinfo?(dminor)

With wfh bugs, I've been working on WebRTC exclusively for the past two months. RDD doesn't really have an owner at the moment, but we're continuing to find bugs. I'm going to follow up with Nils about who should own these, might be me, might be someone else. Leaving needinfo for now.

(In reply to Matt Woodrow (:mattwoodrow) from comment #2)

That suggests that we've used more than 500 million shmems on the RemoteDecoderChild actor, which is a bit concerning.

That counter belongs to the top-level protocol, so RemoteDecoderManagerChild in this case; I don't know how much that changes things. (It's also used for managed actors, but the only one possible here seems to be RemoteDecoderChild, and I wouldn't think there'd be a lot of those?)

I want to also note here that I hit this crash already after ~3min of navigating forward and backward between a Youtube search page, and a specific video.

I discussed this with Nils, there's not yet a clear plan as to who will own RDD bugs. Clearing needinfo.

Flags: needinfo?(dminor)

The severity field is not set for this bug.
:jld, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jld)
Crash Signature: [@ mozilla::ipc::IToplevelProtocol::CreateSharedMemory] → [@ mozilla::detail::MutexImpl::unlock | mozilla::ipc::IToplevelProtocol::CreateSharedMemory ] [@ mozilla::ipc::IToplevelProtocol::CreateSharedMemory]
Crash Signature: [@ mozilla::detail::MutexImpl::unlock | mozilla::ipc::IToplevelProtocol::CreateSharedMemory ] [@ mozilla::ipc::IToplevelProtocol::CreateSharedMemory] → [@ mozilla::ipc::IToplevelProtocol::CreateSharedMemory]
Severity: -- → S3
Flags: needinfo?(jld)
You need to log in before you can comment on or make changes to this bug.