Found while fuzzing m-c 20221215-440856ffde51 (--enable-debug --enable-fuzzing)

To reproduce via Grizzly Replay:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch -d --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.zip --no-harness

WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything alive inside it, that is) AT JS_ShutDown TIME. FIX THIS!

Hit MOZ_CRASH(NSS_Shutdown failed) at /builds/worker/checkouts/gecko/xpcom/build/XPCOMInit.cpp:720

#0 0x7f288b38046e in mozilla::ShutdownXPCOM(nsIServiceManager*) /builds/worker/checkouts/gecko/xpcom/build/XPCOMInit.cpp:720:9
#1 0x7f28925c1642 in XRE_InitChildProcess(int, char**, XREChildData const*) /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:680:16
#2 0x560dacaceca0 in content_process_main /builds/worker/checkouts/gecko/browser/app/../../ipc/contentproc/plugin-container.cpp:57:28
#3 0x560dacaceca0 in main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:359:18
#4 0x7f289f72dd8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#5 0x7f289f72de3f in __libc_start_main csu/../csu/libc-start.c:392:3
#6 0x560dacaa5308 in _start (/home/user/workspace/browsers/m-c-20230105213109-fuzzing-debug/firefox-bin+0x5b308) (BuildId: 2bd152c3a9c8aaaf10fc5d2286bb7e421fb9027f)

A Pernosco session is available here: https://pernos.co/debug/tHUAOpu85y1TK-xvas5aRQ/index.html

Verified bug as reproducible on mozilla-central 20230106214742-7968ae37c117.
The bug appears to have been introduced in the following build range:

Start: 7fac8607d414d792f4530b726f68ad36afb3c545 (20220405212313)
End: 5135fb6675eacd4e4aa46983b4c7821f678544a6 (20220405205608)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7fac8607d414d792f4530b726f68ad36afb3c545&tochange=5135fb6675eacd4e4aa46983b4c7821f678544a6

get and set landing appear in this blame list.

PeerConnectionImpl, RTCRtpTransceiver, RTCRtpSender, and RTCRtpReceiver are holding onto references to one another, and nothing outside of that group is holding onto references to that group. I'm guessing this means that the cycle-collector just has not run on that group yet, and we've run out of time to tear things down?

Yeah, I can see the cycle-collection traversal happen across that group, but no unlinking happens on any of them before the crash. Not sure why...

Ok, looking closer, I see that the RTCRtpReceiver has an extra reference in a DOM reflector, due to the getReceivers call in the test-case. However, that getReceivers call is never actually executed, because the line before throws; I'm guessing this is just a speculative optimization. I am not sure why that reflector is never cleaned up.

Any idea what might be happening here? This is a little too far down into the guts of the JS engine for me to make sense of.

I'll try looking at some cycle collector logs. The presence of the worker in the test case is a bit odd.

Testcase crashes using the initial build (mozilla-central 20221215195521-440856ffde51) but not with tip (mozilla-central 20230317210204-c6b709a45852.)

The bug appears to have been fixed in the following build range:

Start: 6e82cb173a7520832b225fb658b61252db82a6bf (20230313223129)
End: f0bc703cf5319d85a8dbf4bae1a0d9763b2f7e15 (20230314003846)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6e82cb173a7520832b225fb658b61252db82a6bf&tochange=f0bc703cf5319d85a8dbf4bae1a0d9763b2f7e15

tsmith, can you confirm that the above bisection range is responsible for fixing this issue?
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

This is still reported frequently by the fuzzers however the attached test case no longer reproduces the issue.

ni? me if you'd like a new test case and/or a Pernosco session.