(In reply to Jens Stutte [:jstutte] from comment #4) > And it seems that ironically exactly the copy assignment operator of our same `nsTArray` [gives us problems](https://treeherder.mozilla.org/logviewer?job_id=419747130&repo=try&lineNumber=3803) when it is used [inside a class/structure that forms the element we are sorting](https://searchfox.org/mozilla-central/rev/05d1afda588e54be73e31ef4e022dde91f1ed97a/layout/painting/nsDisplayList.cpp#2395,2411,2421). Interestingly this crash happens only in optimized builds, I assume thus that this might be due to invoking the copy assignment operator on uninitialized memory? This probably merits its own bug, we might miss some default initialization. Bug 1626570 explicitly introduced `CopyableTArray` which would probably tell us that `nsTArray` as such is not meant to be copyable. It would be nice to get a better behavior than just crashing, though. In any case it is most probably not wanted to make any [deep copies of array members here](https://searchfox.org/mozilla-central/rev/05d1afda588e54be73e31ef4e022dde91f1ed97a/layout/painting/nsDisplayList.cpp#2395,2411,2421) just for sorting.
Bug 1839051 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Note that bug 1626570 explicitly introduced `CopyableTArray` which would probably tell us that `nsTArray` as such is not meant to be copyable.