Убийственная связка из NSCache и UINib

Это легко видеть по стекам, в которых посылается release (и вызывается dealloc). Я этот стек не прикладывал, но проверял этот факт.

Убийственная связка из NSCache и UINib

Чтобы получить интересный креш ) А если серьезно, то это оптимизировало работу гуйни, чтобы не загружать xib каждый раз. Насколько эта оптимизация была актуальна сейчас не скажу, но подозреваю, что при добавлении дала адекватные цифры.

Повреждение стека в одном из методов NSString

XCode 6, настройки дефолтные. Но тут, пожалуй, не важно как мы собираем, когда проблема в системном фреймворке. Зависеть будет от ОСи на девайсе (ну и архитектуры бинаря). Пробовал на нескольких девайсах с iOS 8 (может и семерка была).

Убийственная связка из NSCache и UINib

Никакого использования UI из фона в нашем коде не было. Просто объекты UINib кешировались (в главном потоке). А вот NSCache чистит свое содержимое в фоне — отсюда и возникает использование неглавного потока. Но, как я уже написал, обвинять тут NSCache некорректно.

Повреждение стека в одном из методов NSString

Не только в корейском, в другой ссылке, которую я привел используются китайские иероглифы. С определенностью тоже не очень, если поменять начало строки (где не иероглифы), то может и не упасть. В общем, просто непредсказуемое повреждение стека (могут быть случаи и без явного креша). А чтобы понять конкретно, как именно сносится стек, надо смотреть исходники функции (или реверсить) — но это уже дело Apple )

Повреждение стека в одном из методов NSString

Добавил ссылку.