Всем привет! Наткнулся на интересную статью, в которой автор рассказывает про поиск причины падения приложения при сворачивании на одном из экранов. В краш-логе не было ни одной строчки кода приложения, только системные фреймы QuartzCore, UIKit и Core Animation. Address Sanitizer ничего не показывал, а воспроизвести проблему без долгих танцев с бубном не получалось.
Что предложил автор:
Вместо того чтобы гадать, он взялся за LLDB. Сначала посмотрел bt (backtrace) - стек вызовов в момент падения. Анализируя его снизу вверх, стало ясно: приложение сворачивалось, система делала снимок экрана, обходила иерархию вьюх и у одной из них запрашивала superview. Именно там и происходил краш.
Дальше - frame select 0 и register read. В регистре x15 отладчик показал символ CrashExample.PlayerView - намек, что проблема связана с плеерным view. А падающая инструкция (ldr x8, [x8,
#0x8]) указала, что регистр x8 был нулевым. Чтение по адресу 0x8 и вызывало EXC_BAD_ACCESS.К чему это привело:
В коде нашли метод, который удалял playerLayer из суперслоя, но саму PlayerView из иерархии не убирал. Вьюха остается в subviews, но ее слой уже мертв. Когда система доходит до нее при обходе, случается краш.
Исправление оказалось простым: вместо ручного удаления слоя вызывать playerView.removeFromSuperview().
💡 Вывод:
Статья - хороший пример того, что делать, когда краш-лог не содержит полезных фреймов, а санитайзеры молчат. LLDB не панацея, но умение читать backtrace, смотреть регистры и дизассемблер может превратить часы гадания в целенаправленный поиск.
➡️ Подписаться на канал
Мобильный трудоголик