Found by Florian in https://treeherder.mozilla.org/logviewer?job_id=354394127&repo=try&lineNumber=2735

This assertion is in fact incorrect at that point: The ThreadRegistration is still registered in the public ThreadRegistry, so another thread could find it and lock its mutex.
The assertion should be moved after ThreadRegistry::Unregister(OnThreadRef{*this});.

The data-mutex lock assertion in the ThreadRegistration destructor was done too early, because that ThreadRegistration could still be publicly accessible through the ThreadRegistry at that time.
This assertion is now moved after ThreadRegistry::UnregisterThread, after which other threads shouldn't have access to this ThreadRegistration anymore.

This patch also adds a stress gtest that registers and unregisters a thread many times, and a separate thread attempts to access and lock the test thread data. It did trigger the previous assertion before it was moved.

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

Is there a real-world impact here which would justify backport consideration or can this fix ride the trains to release?

https://hg.mozilla.org/mozilla-central/rev/9b9f8bfe2625

(In reply to Ryan VanderMeulen [:RyanVM] from comment #3)

Is there a real-world impact here which would justify backport consideration or can this fix ride the trains to release?

Thank you Ryan for asking.
The problem was a badly-placed MOZ_ASSERT, so it would only affect DEBUG builds, and only when running the profiler.
I think the population of Profiler users on DEBUG non-Nightly is tiny (zero?). And we haven't seen this assertion trigger in our CI or crash reports either. So I don't think it's worth backporting.