# \[RESOLVED - my bad!\] Problems with OwnedArray under ARM/M1 **URL:** \ **Category:** Audio Plugins\ **Created:** [January 21, 2022, 4:46pm UTC](https://forum.juce.com/t/resolved-my-bad-problems-with-ownedarray-under-arm-m1/49788 "2022-01-21T16:46:32Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![HowardAntares](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/howardantares/32/4629_2.png) [@HowardAntares](https://forum.juce.com/u/HowardAntares)\ **Post date:** [January 21, 2022, 4:46pm UTC](https://forum.juce.com/t/resolved-my-bad-problems-with-ownedarray-under-arm-m1/49788/1 "2022-01-21T16:46:32Z")
I recently added support for building universal binaries of my plugin, and am testing under ARM on my new M1 Mac Mini. I use an OwnedArray to store polymorphic objects (the base class or one of three derived classes). This is all working fine on the PC and on Intel Macs or under Rosetta on M1s. But when run using the ARM processor, pretty much every add or remove I make to the array trashes it somehow, leading to bizarre behaviors and eventually a crash. I’m using the 6.1.4 JUCE SDK. Are there any known issues with OwnedArray under ARM? At this point, everything seems so totally screwed up that I’m looking at maybe ditching OwnedArray altogether and rewriting all of that code to use something from the standard library like a vector or list. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [January 21, 2022, 5:01pm UTC](https://forum.juce.com/t/resolved-my-bad-problems-with-ownedarray-under-arm-m1/49788/2 "2022-01-21T17:01:33Z")
Are you sure OwnedArray itself is the problem? It sounds more plausible to me that it’s how you used the array. For example adding/removing from OwnedArray will invalidate the iterators, and in case of those being accessed from multiple threads there could certainly be weird things happening. I personally don’t use OwnedArray in my own code, but it’s in a huge amount of commonly used JUCE classes which work fine on M1, so I’d be really surprised if it’s the direct cause of the bug you’re experiencing. ---
**Author:** ![HowardAntares](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/howardantares/32/4629_2.png) [@HowardAntares](https://forum.juce.com/u/HowardAntares)\ **Post date:** [January 21, 2022, 5:20pm UTC](https://forum.juce.com/t/resolved-my-bad-problems-with-ownedarray-under-arm-m1/49788/3 "2022-01-21T17:20:15Z")
Yep, sure enough, it was me. IN _one_ place in my huge code base, I had used a std::unique\_ptr, and used get() on it to add it to the array. Part of “modernizing” my code base. Restored that one place to using a raw pointer, and it is working again. No idea why this only caused a problem. on M1/ARM, but happy to have found the issue. A note I read here about using std::unique\_ptr with OwnedArray led me to search for that. This forum is a godsend! ---
**Author:** ![HowardAntares](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/howardantares/32/4629_2.png) [@HowardAntares](https://forum.juce.com/u/HowardAntares)\ **Post date:** [January 21, 2022, 5:31pm UTC](https://forum.juce.com/t/resolved-my-bad-problems-with-ownedarray-under-arm-m1/49788/4 "2022-01-21T17:31:58Z")
Yeah, I know, I could have changed it to .release(), but no reason for a unique\_ptr in only this one location and none of the other functions that access that array. ---
**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\ **Post date:** [January 21, 2022, 5:47pm UTC](https://forum.juce.com/t/resolved-my-bad-problems-with-ownedarray-under-arm-m1/49788/5 "2022-01-21T17:47:38Z")
Not sure if I got it right, but the most “correct” way – at least the way that is probably closest to how `std::unique_ptr` is intended to be used from my point of view is moving it when you transfer ownership from one instance to another or to some instance that is capable of taking over ownership by passing a unique ptr to it like the `juce::OwnedArray` is: ```auto struct Foo {}; struct Bar : Foo {}; juce::OwnedArray array; std::unique_ptr bar; array.add (std::move (bar)); ``` Beneath being technically safe, to me code like that is very explicit about ownership to the reader. ---
**Author:** ![HowardAntares](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/howardantares/32/4629_2.png) [@HowardAntares](https://forum.juce.com/u/HowardAntares)\ **Post date:** [January 21, 2022, 6:02pm UTC](https://forum.juce.com/t/resolved-my-bad-problems-with-ownedarray-under-arm-m1/49788/6 "2022-01-21T18:02:06Z")
Ah, right. Still not used to unique\_ptrs. But since all my other code for this array uses raw pointers, no need to use a unique\_ptr in this one function only, so I reverted it to a raw pointer for now.