@mikeash, @Catfish-Man, any ideas where to start?

Looks like LegacyMechanic.append is accessing a bad pointer, either a junk value or a pointer to an object that has already been destroyed. swift_isUniquelyReferenced_nonNull_native just accesses the refcount field and returns the appropriate value. I'd suggest looking for thread safety problems or other memory management trouble. trololo (JIRA User), if you'd like to post a full crash log, I may be able to give a bit more info.

Comment by Vyacheslav (JIRA)

Ok . I’ll attach all crash logs asap

Cool! I was about to edit my comment to say that it's even better if you can attach all of your crash logs, but you're clearly on top of it.

Comment by Vyacheslav (JIRA)

Done.

Comment by Vyacheslav (JIRA)

Btw, if you need more info, I will provide, of course .

Thanks! This is interesting.

All three crashes are at the very first instruction of swift_isUniquelyReferenced_nonNull_native, which is ldr x8, [x0, #​0x8]. x0 contains the address of the object being checked. In all three crash logs, x0 contains the value 0x8000000000000000 which is clearly not anything like a valid object pointer.

I still think thread safety problems are the thing to look at. Something is overwriting an object pointer you're using, which could be due to your object being destroyed and another object allocated in its place. Two of the logs crashed while doing work inside LegacyInitializationMechanic.execute, and they also were running LegacyInitializationMechanic.execute on another thread at the same time. That location in LegacyInitializationMechanic.execute looks to be mutating a Dictionary. I'd bet it's mutating the same Dictionary on both threads without locking first. Similarly, the third log crashed in AppModelStorage.update while mutating a Set on two threads, and I'd bet that it's mutating the same Set on both threads without locking first.

Comment by Vyacheslav (JIRA)

Ok. I have to read the code. I will write about your clues. Thanks!

Comment by Vyacheslav (JIRA)

Ok. I've looked.

It seems you are right. But I don't actually understand why this code called twice at the same time.

LegacyInitializationMechanic contains dictionary inside.

As AppModelStorage, it seems you are right too. I'm removing and appending the object to the Set. The problem is that I currently don't understand why this method was called twice.

The most obvious solution is to wrap this code by serial operation queue. Am I right? Is it an expected behavior of a Collection?

Yes, it's expected that concurrently mutating a collection on one thread while accessing it (either reading or mutating it) on another thread could result in a crash or unpredictable behavior.

A serial queue would be a great way to fix this. Set it up so that all accesses to any given collection happen on one serial queue and everything will work.