Чем опасна команда po в LLDB?

Опасности команды po в LLDB

Команда po (print object) в LLDB — это мощный инструмент для инспекции объектов во время отладки, но её неосторожное использование может привести к серьёзным побочным эффектам и неожиданному поведению программы. Основные опасности заключаются в непреднамеренном выполнении кода и изменении состояния приложения.

1. Вызов геттеров и вычисляемых свойств

Когда вы используете po для объекта, LLDB фактически вызывает его description метод (или debugDescription). Если класс переопределяет эти методы или если у объекта есть вычисляемые свойства (computed properties), их геттеры будут выполнены. Это может привести к:

• Побочным эффектам: Геттер может изменять состояние объекта или выполнять другие операции (например, кэширование, логирование, сетевые запросы).
• Рекурсии: Если description использует другие свойства, которые, в свою очередь, вызывают description, возникнет бесконечная рекурсия и креш.

class DangerousObject {
    var value: Int {
        didSet {
            print("Side effect: value changed to \(value)")
            // Неожиданное логирование или изменение состояния
        }
    }
    
    var debugDescription: String {
        return "Value: \(value)" // Вызывает didSet у value!
    }
    
    init(value: Int) {
        self.value = value
    }
}

// В LLDB: po myObject -> может вызвать didSet и изменить поведение

2. Изменение состояния приложения

Если в description или геттерах заложена логика, меняющая состояние, po может незаметно модифицировать данные:

• Счётчики или флаги: Увеличение счётчика обращений к свойству.
• Кэширование: Первое обращение к свойству инициирует загрузку данных и меняет внутренний кэш.
• Инвалидация состояний: Сброс флагов готовности данных.

3. Проблемы с многопоточностью

Выполнение po в многопоточной среде особенно рискованно:

• Гонки данных: po может читать данные в момент их изменения другим потоком, приводя к неконсистентным выводам.
• Блокировки: Если геттер использует блокировки (locks), po может вызвать взаимную блокировку (deadlock), особенно если отладчик прервал поток уже удерживающий lock.

class ThreadSafeObject {
    private let lock = NSLock()
    private var internalData: String = "secret"
    
    var data: String {
        lock.lock() // Блокировка захватывается здесь
        defer { lock.unlock() }
        return internalData
    }
}

// В LLDB: po объекта в момент, когда другой поток уже держит lock -> deadlock

4. Производительность и креши

• Медленные вычисления: Если description выполняет тяжёлые операции (например, сериализацию большого графа объектов), это замедлит отладку и может "подвесить" интерфейс.
• Креши из-за некорректного состояния: Если объект находится в неконсистентном состоянии (например, частично инициализирован, повреждён), вызов его методов через po может привести к немедленному крешу.

5. Отличия от p и frame variable

Важно отличать po от команд p (print) и frame variable:

• p вычисляет выражение, но может избежать вызова description.
• frame variable просто читает память без вызова каких-либо методов, что безопаснее.
• po всегда пытается форматировать объект, вызывая его методы.

Рекомендации по безопасному использованию

1. Используйте frame variable для быстрого просмотра значений полей без побочных эффектов.
2. Проверяйте реализацию description в своих классах: избегайте побочных эффектов в геттерах и методах описания.
3. В сомнительных случаях применяйте p с явным приведением типов: p (NSObject *)myObject.
4. При отладке многопоточных кодов будьте предельно осторожны или используйте дампы памяти (memory read).
5. Рассматривайте po как операцию с побочными эффектами, а не просто "печать в лог".

Итог: po — это не пассивный "осмотр" объекта, а активное выполнение кода. Непреднамеренные побочные эффекты могут исказить поведение отлаживаемой программы, скрыть баги или создать новые. Всегда оценивайте риски, особенно в продакшн-коде или при работе с чужими библиотеками.