Точки прерывания исключения - результаты LLDB против GDB - PullRequest
2 голосов
/ 25 января 2012

Я искал темы специально для этого вопроса, но не нашел ничего похожего на мой опыт.Прости меня, если я не заметил ответ.Я знаком с GDB и точками исключения, точками останова и т. Д., Но следующий тест отладки в GDB против LDB не дал мне правдоподобного ответа.

Глобальные тестовые значения

  • Xcode 4.2.1
  • Новый проект с одним окном (шаблон по умолчанию без изменений)
  • Дуга включена
  • Раскадровка включена

Случай 1 - отладчик GDB

Значения точек останова исключения:

  • Исключение - все
  • Разрыв - выбрасывать
  • Аргументы - нет
  • Результат - без сбоев

Случай 2 - отладчик LLDB

Значения точек останова исключения:

  • Исключение - все
  • Взлом на - Бросить
  • Аргументы - Нет
  • Результат - Сбой с Sigbart и машинным кодом;нет различимой трассировки стека

Случай 3 - отладчик LLDB

Значения точки останова исключения:

  • Исключение - Objective-C
  • Break on - Throw
  • Аргументы - нет
  • Результат - без сбоев

Случай 4 - Отладчик LLDB

Значения точки останова исключения:

  • Исключение - C ++
  • Разбить на - Бросить
  • Аргументы - Нет
  • Результат - Сбой с Sigbart иМашинный код;нет заметной трассировки стека

Вопрос: Должен ли я просто предположить, что выбор "Objective-C" в качестве опции исключения является безопасным способом, или я потенциально игнорирую явноевопрос?Насколько я понимаю, с Xcode 4.2.1 рекомендуется использовать LLDB, и я бы хотел.Тем не менее, мне любопытно, о результатах выше.

Заранее благодарим за все ответы сообщества!

1 Ответ

0 голосов
/ 25 января 2012

Благодаря вдумчивому предложению @ Mike K мне удалось решить мою проблему потенциального игнорирования явной проблемы.

Когда я воспроизводил вышеупомянутый сценарий на реальном устройствеiPhone / iPad, Случаи 2 и 4 , использующие LLDB, больше не приводят к сбою, и приложение работает так, как задумано.Кажется, проблема ограничена симулятором.

Меня интересует первопричина проблемы на симуляторе для потомков, но я очень рад, что могу продолжать использовать LLDB, как и предполагалось.

...