nsTArray.h is missing the template magic to make sure it copies JS::ObjectPtr via construction/destruction rather than memmove. This is bad because ObjectPtr contains a Heap<JSObject*> and this can be referenced directly by the store buffer. memmove does not update store buffer pointers. This has probably been causing crashes for a while.

Patch to add the MOZ_NON_MEMMOVABLE attribute to classes that can be pointed to by the storebuffer.
Also adds a move constructor to ObjectPtr that clears the source object. This is necessary so you can move live instances without the destructor of the source object asserting because finalize() hasn't been called.

Comment on attachment 8908603[details][diff][review]bug1400003-nstarray-changes
[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Very difficult.
Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
No.
Which older supported branches are affected by this flaw?
Everything back to FF33.
If not all supported branches, which bug introduced the flaw?
This was an omission in bug 877762 but it's only been a problem since bug 990729.
Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
This should be trivial.
How likely is this patch to cause regressions; how much testing does it need?
Unlikely.

(In reply to Jon Coppeard (:jonco) from comment #7)
> (In reply to Steve Fink [:sfink] [:s:] from comment #6)
> ObjectPtr contains Heap<JSObject*> so should be treated as
> MOZ_NON_MEMMOVABLE.
>
> I did a try build to check this with the MOZ_NON_MEMMOVABLE attribute on
> Heap<T> but without the changes to nsTArray:
>
> https://treeherder.mozilla.org/logviewer.
> html#?job_id=131248949&repo=try&lineNumber=11202
Ah! That makes sense, I just didn't think of it.

Comment on attachment 8908603[details][diff][review]bug1400003-nstarray-changes
This approval request is for both patches in this bug. Do the patches need to landed simultaneously on Beta and ESR52? I can do this uplift request for Beta, and could probably do the rebase/uplift request for ESR52, but would feel slightly more comfortable if jonco did the rebase/uplift request for ESR52.
Approval Request Comment
[Feature/Bug causing the regression]: bug 990729/bug 877762
[User impact if declined]: getting pwned
[Is this code covered by automated tests?]: Yes?
[Has the fix been verified in Nightly?]: No
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Straightforward code changes; jonco also said it was not risky :P
[String changes made/needed]: None