This bug is for crash report bp-37865c67-0ab0-4567-985f-919d70200107.

Top 6 frames of crashing thread:

0 XUL mozilla::recordreplay::child::ChannelMessageHandler toolkit/recordreplay/ipc/ChildIPC.cpp:89
1 XUL std::__1::__function::__func<void  /builds/worker/fetches/clang/include/c++/v1/functional:1707
2 XUL mozilla::recordreplay::Channel::ThreadMain toolkit/recordreplay/ipc/Channel.cpp:145
3 libsystem_pthread.dylib _pthread_start 
4 libsystem_pthread.dylib thread_start 
5 XUL XUL@0x3d1691f 

There are 2 crashes (from 1 installation) in nightly 74 with buildid 20200106215403. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1606447.

[1] https://hg.mozilla.org/mozilla-central/rev?node=052285013972

Adding a similar signature which shows up with the same build id.

I think this was fixed as part of bug 1603945 --- we would previously try to forward messages to processes that have crashed or terminated, which could end up going to the wrong process because the fd had been closed and its number reused by the kernel later on.

We're still seeing crashes after the fix in bug 1603945 landed though.

WebReplay frontend has been removed, and it looks like this crash has gone away.