Found while fuzzing m-c 20220808-713ea960c352 (--enable-debug --enable-fuzzing)

A Pernosco session is available here: https://pernos.co/debug/QFvsRq7VwQD4FUg5r3ebXA/index.html

The test cases reported by fuzzers seem to require multiple parts. If a test case is required please ni? me and I can try building a stand alone test case.

Fuzzers started hitting this on Aug 5th so I assume it is also a regression from Bug 1769802.

Assertion failure: mRawPtr != nullptr (You can't dereference a NULL RefPtr with operator->().), at /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:315

#0 0x7f694817a99e in mozilla::dom::RTCRtpTransceiver::BreakCycles() /builds/worker/checkouts/gecko/dom/media/webrtc/jsapi/RTCRtpTransceiver.cpp
#1 0x7f6948194b61 in mozilla::dom::RTCRtpTransceiver::cycleCollection::Unlink(void*) /builds/worker/checkouts/gecko/dom/media/webrtc/jsapi/RTCRtpTransceiver.cpp:134:10
#2 0x7f6944096f6e in nsCycleCollector::CollectWhite() /builds/worker/checkouts/gecko/xpcom/base/nsCycleCollector.cpp:3074:26
#3 0x7f694409882b in nsCycleCollector::Collect(mozilla::CCReason, ccIsManual, js::SliceBudget&, nsICycleCollectorListener*, bool) /builds/worker/checkouts/gecko/xpcom/base/nsCycleCollector.cpp:3440:26
#4 0x7f694409adde in nsCycleCollector_collect(mozilla::CCReason, nsICycleCollectorListener*) /builds/worker/checkouts/gecko/xpcom/base/nsCycleCollector.cpp:3920:28
#5 0x7f6945ddaaab in nsJSContext::CycleCollectNow(mozilla::CCReason, nsICycleCollectorListener*) /builds/worker/checkouts/gecko/dom/base/nsJSEnvironment.cpp:1418:3
#6 0x7f6946f7df48 in mozilla::dom::FuzzingFunctions_Binding::cycleCollect(JSContext*, unsigned int, JS::Value*) /builds/worker/workspace/obj-build/dom/bindings/FuzzingFunctionsBinding.cpp:132:3
#7 0x7f694c67a157 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:455:13
#8 0x7f694c679a11 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:543:12
#9 0x7f694bc7b018 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1586:10
#10 0xee952f7d4c3  (<unknown module>)

Set release status flags based on info from the regressing bug 1769802

:bwc, since you are the author of the regressor, bug 1769802, could you take a look?
For more information, please visit auto_nag documentation.

Looking into it.

It just looks like we're getting more than one unlink call. Easy enough to fix. If it is not too hard, a test-case would be nice to have, but I realize this might be really hard to trigger.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3118bab3d5e9ebb458df4d3ab14c911f90e57c15
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a9de729b8b48e694888f94fcfe778411990ec856

This test case will require a fuzzing build because it uses FuzzingFunctions.cycleCollect() and FuzzingFunctions.garbageCollect().

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20220810212956-d9acc6dde178.
The bug appears to have been introduced in the following build range:

Start: d2cf2ff27055bfabec354e3acfca59ce4d68ea64 (20220805134817)
End: 113f49c15b47806a1da3a834cca2e3a8ce1cea34 (20220805162407)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d2cf2ff27055bfabec354e3acfca59ce4d68ea64&tochange=113f49c15b47806a1da3a834cca2e3a8ce1cea34

I'm having no luck reproducing this on my local machine on m-c, so I cannot verify the potential fix. Here are some fuzzing builds with that changeset, is there any way to point bugmon at them?

https://treeherder.mozilla.org/jobs?repo=try&revision=4c65c58bae7d875d1dd5a82faf28f7afbf6e0ce9

(In reply to Byron Campen [:bwc] from comment #8)

I'm having no luck reproducing this on my local machine on m-c, so I cannot verify the potential fix. Here are some fuzzing builds with that changeset, is there any way to point bugmon at them?

https://treeherder.mozilla.org/jobs?repo=try&revision=4c65c58bae7d875d1dd5a82faf28f7afbf6e0ce9

I don't think bugmon has that ability. I tested locally and the issue no longer seems to be reproducible with the provided try build, thanks!

For reference I used Grizzly to help simplify replay of the test case. It is not required but it is helpful.

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

To use the try build instead substitute the fuzzfetch line with
$ python -m fuzzfetch --fuzzing -d --try --build 4c65c58bae7d875d1dd5a82faf28f7afbf6e0ce9 -n firefox

https://hg.mozilla.org/mozilla-central/rev/ff3eff94d0f7

Bugmon Analysis
Verified bug as fixed on rev mozilla-central 20220820094621-b1f99e866232.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.