Ответ 1
Я могу воспроизвести это с помощью простого тестового приложения sans WatchKit. Приложение состоит из NSTimer, который печатает "Таймер уволен" каждую секунду. (Этот код на 100% правильный;). Ничего не отображается в журнале после того, как я вручную привязал процесс.
Насколько я знаю, NSLog выводит на stderr, я предполагаю, что отладчик не перенаправляет stderr на терминал Xcode.
Если вы используете консольное приложение или терминал для просмотра своих журналов, вы можете это сделать. iOS8 хранит журналы моделирования в ~/Library/Logs/CoreSimulator/<Device-UUID>
. В этом каталоге вы найдете system.log, который содержит весь ваш вывод NSLog
.
Вы можете посмотреть его в терминале (cat
, grep
, tail
) или открыть его в Console.app.
Apple подтверждает, что (по крайней мере для GDB) в Техническая нота TN2239: Маска отладки iOS.
Консольный выход
Многие программы и даже многие системные среды, отладка печати сообщений в stderr. Назначение для этого вывода в конечном счете контролируемый программой: он может перенаправлять stderr на любой пункт назначения, который он выбирает. Однако в большинстве случаев программа не redirect stderr, поэтому выход переходит к назначению по умолчанию унаследованный программой из среды запуска. Это обычно одно из следующего:
- Если вы запустите приложение GUI, поскольку оно будет запущено обычным пользователь, система перенаправляет любые сообщения, напечатанные на stderr, на системный журнал. Вы можете просмотреть эти сообщения, используя описанные методы ранее.
- Если вы запускаете программу из Xcode, вы можете увидеть ее Выход stderr в окне консоли отладчика Xcode (выберите консоль пункт меню из меню "Выполнить", чтобы увидеть это окно).
Присоединение к (с помощью приложения Xcode Attach to Process или приложения команда в GDB) автоматически не подключает программу stderr к ваше окно GDB. Вы можете сделать это из GDB, используя трюк описанных в разделе "Видение stdout и stderr After Attaching" Техническая нота TN2030, "GDB для ветеранов MacsBug".
Указанные TN2030 больше не доступны на их сервере (mirror). Он показал, как вы можете перенаправить stdout и stderr на консоль Xcode. Однако, поскольку shell tty
не является допустимой командой для LLDB, это не поможет. Но, возможно, есть другой способ получить доступ к консоли консоли tty Xcodes, поэтому я присоединяю важную часть этого TN.
Просмотр stdout и stderr После присоединения
Если вы присоедините GDB к процессу (в отличие от запуска процесса изнутри GDB), вы не сможете увидеть ничего, что процесс печатает на stdout или stderr. Программы, запускаемые Finder, обычно есть stdout и stderr, подключенные к "/dev/console", поэтому информация они печатаются на консоль. Вы можете просмотреть это, запустив Консольное приложение (в папке "Утилиты" ), однако, это неудобно смотреть в отдельном окне. Другая альтернатива заключается в подключении процесса stdout или stderr к терминальному устройству для окна терминала GDB. В листинге 9 показано, как это сделать.
Листинг 9. Подключение stdout и stderr к терминальному устройству GDB.
(gdb) attach 795 [... output omitted ...] (gdb) call (void) DebugPrintMenuList() No output )-: Close the stdout and stderr file descriptors. (gdb) call (void) close(1) (gdb) call (void) close(2) Determine the name of the terminal device for GDB itself. (gdb) shell tty /dev/ttyp1 Reopen stdout and stderr, but connected to GDB terminal. The function results should be 1 and 2; if not, something is horribly wrong. (gdb) call (int) open("/dev/ttyp1", 2, 0) $1 = 1 (gdb) call (int) open("/dev/ttyp1", 2, 0) $2 = 2 Try the DebugPrintMenuList again. (gdb) call (void) DebugPrintMenuList() Yay output! Index MenuRef ID Title ----- ---------- ---- ----- <regular menus> 00001 0x767725D3 -21629 Ed 00002 0x76772627 1128 <Apple> 00003 0x767726CF 1129 File 00004 0x76772567 1130 Edit [... remaining output omitted ...]