Xcode 附加到进程不显示 NSLog
Xcode attach to process doesn't display NSLog
我刚刚开始使用 Apple Watch。我从“Five Minute Watchkit”中找到了有关在模拟器中获取 iOS 应用程序和手表套件应用程序的说明 运行 以及附加到 LLDB 调试器的两个进程。
我所做的是启动并退出 iOS 应用程序以在 sim 卡中安装当前版本。然后我切换到 watchKit 方案并启动它,它会在手表模拟器上显示我的手表应用 UI。
然后我在模拟器中启动相应的 iOS 应用程序,然后在 Xcode 菜单中使用 "attach to process" 将调试器附加到 运行 iOS 应用
这行得通。我可以在手表套件 InterfaceController 或我的 iOS 应用程序中设置断点,调试器会在它应该中断的时候中断。
但是,我在 iOS 应用程序的调试控制台中没有看到 NSLog() 语句。 (我确实看到了来自 WatchKit 扩展代码的日志语句。)如果我在我的 iOS 应用程序中设置了一个断点,它会在它应该停止的时候停在那个断点处。我假设 NSLog 缺少控制台输出与附加到 sim 上的 运行 进程有关,而不是从 Xcode 启动它,但我不知道那是什么。
(顺便说一句,将操作附加到从断点调用 NSLog 的断点也不会显示,但 "log message" 调试器命令会显示。
有人有什么见解吗?)
编辑:
iOS 应用程序中的代码似乎无关紧要。在我的例子中,它是一个非常简单的 IBAction,它附加到 iOS 应用故事板中的一个按钮:
- (IBAction)buttonAction:(UIButton *)sender;
{
NSLog(@"Button clicked on iPhone");
}
我可以在该 NSLog 语句上设置断点。调试器在该行停止,但我没有在调试控制台中看到日志语句。
我可以用一个简单的测试应用重现它,没有 WatchKit。该应用程序包含一个每秒打印 "Timer fired" 的 NSTimer。 (此代码 100% 正确;)。手动附加到进程后,日志中没有任何显示。
据我所知,NSLog 输出到 stderr,我想附加调试器不会将 stderr 重定向到 Xcode 终端。
如果您可以使用控制台应用程序或终端查看您的日志,您可以这样做。 iOS8 将模拟器日志存储在 ~/Library/Logs/CoreSimulator/<Device-UUID>
中。在此目录中,您会找到一个 system.log,其中包含您所有的 NSLog
输出。
您可以在终端(cat
、grep
、tail
)中查看它,或者在Console.app中打开它。
Apple 在 Technical Note TN2239: iOS Debugging Magic 中确认(至少对于 GDB)。
Console Output
Many programs, and indeed many system frameworks, print debugging
messages to stderr. The destination for this output is ultimately
controlled by the program: it can redirect stderr to whatever
destination it chooses. However, in most cases a program does not
redirect stderr, so the output goes to the default destination
inherited by the program from its launch environment. This is
typically one of the following:
- If you launch a GUI application as it would be launched by a normal
user, the system redirects any messages printed on stderr to the
system log. You can view these messages using the techniques described
earlier.
- If you run a program from within Xcode, you can see its
stderr output in Xcode's debugger Console window (choose the Console
menu item from the Run menu to see this window).
Attaching to a
running program (using Xcode's Attach to Process menu, or the attach
command in GDB) does not automatically connect the program's stderr to
your GDB window. You can do this from within GDB using the trick
described in the "Seeing stdout and stderr After Attaching" section of
Technical Note TN2030, 'GDB for MacsBug Veterans'.
提到的 TN2030 在他们的服务器上不再可用 (mirror)。它展示了如何将 stdout 和 stderr 重定向到 Xcode 控制台。但是,由于 shell tty
不是 LLDB 的有效命令,因此它不会有太大帮助。但也许有不同的方式来访问 tty Xcodes 控制台使用,所以我附上了那个 TN 的重要部分。
Seeing stdout and stderr After Attaching
If you attach GDB to a process (as opposed to starting the process
from within GDB), you won't be able to see anything that the process
prints to stdout or stderr. Programs launched by the Finder typically
have stdout and stderr connected to "/dev/console", so the information
they print goes to the console. You can view this by launching the
Console application (in the Utilities folder), however, it's
inconvenient to have to look in a separate window. Another alternative
is to connect the process's stdout or stderr to the terminal device
for GDB's Terminal window. Listing 9 shows how to do this.
Listing 9. Connecting stdout and stderr to GDB's terminal device.
(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's terminal.
The function results should be 1 and 2; if not, something
is horribly wrong.
(gdb) call (int) open("/dev/ttyp1", 2, 0)
= 1
(gdb) call (int) open("/dev/ttyp1", 2, 0)
= 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 ...]
使用 Xcode 7.2 版和 iOS 9.2 等,我发现了以下作品:
- 关闭 phone 应用和手表应用
- Select Watch Extension Target 然后点击 Cmd+R (build and 运行)
- Select Phone 目标并按 Ctrl+Cmd+R(运行没有建筑)
在我的例子中,我在他们的模拟器中安装了这两个应用程序,并为这两个应用程序获取了 NSLog 输出。我不需要单独附加。希望这有帮助。
在我的例子中设置了自动查看NSLog,之前根本不显示
https://developer.apple.com/library/ios/qa/qa1747/_index.html
插入设备并打开Xcode
从菜单栏中选择 Window -> 设备
在左列的“设备”部分下,选择设备
要查看设备控制台,请单击右侧面板左下方的向上三角形
单击右下角的向下箭头将控制台另存为文件
当您的 Provisioning 配置文件设置为 Ad Hoc 或 Distribution 时 Xcode 不显示日志,您需要设置 development 才能查看日志
为了补充 Filipp Keks 的回答,这里有一个比公认的答案更简单的方法的直观表示。
来自 Filipp Keks 的回答:
插入设备并打开Xcode
从菜单栏中选择 Window -> 设备
在左列的“设备”部分下,选择设备
要查看设备控制台,请单击右侧面板左下方的向上三角形
单击右下角的向下箭头将控制台另存为文件
此屏幕截图是在设备 window 的 Xcode 7.3.1 中截取的。
我通过这个现已关闭的问题 (Xcode console empty after attaching to process) 来到这个问题。
我的问题是 Xcode 中的 调试控制台没有显示任何内容(只是一个空白框)。
我的解决方案是底部的一个小开关,它在“可变视图”和实际调试控制台之间切换。
这可能无法解决显示 NSLog 消息的问题,但在调试在后台启动的应用程序时可能会有所帮助。
您可以使用允许您记录消息的断点功能。
想法是:
- 创建断点并选中“评估操作后自动继续”
- 添加“日志消息”操作(您也可以使用表达式并打印出值,例如:“日志消息@variable@”)
- 使用预期的进程名称附加调试器(XCode 将等待进程启动)
- 触发应用启动。
致谢名单和详情:
https://fluffy.es/how-to-debug-app-which-got-launched-push-notification/
我刚刚开始使用 Apple Watch。我从“Five Minute Watchkit”中找到了有关在模拟器中获取 iOS 应用程序和手表套件应用程序的说明 运行 以及附加到 LLDB 调试器的两个进程。
我所做的是启动并退出 iOS 应用程序以在 sim 卡中安装当前版本。然后我切换到 watchKit 方案并启动它,它会在手表模拟器上显示我的手表应用 UI。
然后我在模拟器中启动相应的 iOS 应用程序,然后在 Xcode 菜单中使用 "attach to process" 将调试器附加到 运行 iOS 应用
这行得通。我可以在手表套件 InterfaceController 或我的 iOS 应用程序中设置断点,调试器会在它应该中断的时候中断。
但是,我在 iOS 应用程序的调试控制台中没有看到 NSLog() 语句。 (我确实看到了来自 WatchKit 扩展代码的日志语句。)如果我在我的 iOS 应用程序中设置了一个断点,它会在它应该停止的时候停在那个断点处。我假设 NSLog 缺少控制台输出与附加到 sim 上的 运行 进程有关,而不是从 Xcode 启动它,但我不知道那是什么。
(顺便说一句,将操作附加到从断点调用 NSLog 的断点也不会显示,但 "log message" 调试器命令会显示。 有人有什么见解吗?)
编辑: iOS 应用程序中的代码似乎无关紧要。在我的例子中,它是一个非常简单的 IBAction,它附加到 iOS 应用故事板中的一个按钮:
- (IBAction)buttonAction:(UIButton *)sender;
{
NSLog(@"Button clicked on iPhone");
}
我可以在该 NSLog 语句上设置断点。调试器在该行停止,但我没有在调试控制台中看到日志语句。
我可以用一个简单的测试应用重现它,没有 WatchKit。该应用程序包含一个每秒打印 "Timer fired" 的 NSTimer。 (此代码 100% 正确;)。手动附加到进程后,日志中没有任何显示。
据我所知,NSLog 输出到 stderr,我想附加调试器不会将 stderr 重定向到 Xcode 终端。
如果您可以使用控制台应用程序或终端查看您的日志,您可以这样做。 iOS8 将模拟器日志存储在 ~/Library/Logs/CoreSimulator/<Device-UUID>
中。在此目录中,您会找到一个 system.log,其中包含您所有的 NSLog
输出。
您可以在终端(cat
、grep
、tail
)中查看它,或者在Console.app中打开它。
Apple 在 Technical Note TN2239: iOS Debugging Magic 中确认(至少对于 GDB)。
Console Output
Many programs, and indeed many system frameworks, print debugging messages to stderr. The destination for this output is ultimately controlled by the program: it can redirect stderr to whatever destination it chooses. However, in most cases a program does not redirect stderr, so the output goes to the default destination inherited by the program from its launch environment. This is typically one of the following:
- If you launch a GUI application as it would be launched by a normal user, the system redirects any messages printed on stderr to the system log. You can view these messages using the techniques described earlier.
- If you run a program from within Xcode, you can see its stderr output in Xcode's debugger Console window (choose the Console menu item from the Run menu to see this window).
Attaching to a running program (using Xcode's Attach to Process menu, or the attach command in GDB) does not automatically connect the program's stderr to your GDB window. You can do this from within GDB using the trick described in the "Seeing stdout and stderr After Attaching" section of Technical Note TN2030, 'GDB for MacsBug Veterans'.
提到的 TN2030 在他们的服务器上不再可用 (mirror)。它展示了如何将 stdout 和 stderr 重定向到 Xcode 控制台。但是,由于 shell tty
不是 LLDB 的有效命令,因此它不会有太大帮助。但也许有不同的方式来访问 tty Xcodes 控制台使用,所以我附上了那个 TN 的重要部分。
Seeing stdout and stderr After Attaching
If you attach GDB to a process (as opposed to starting the process from within GDB), you won't be able to see anything that the process prints to stdout or stderr. Programs launched by the Finder typically have stdout and stderr connected to "/dev/console", so the information they print goes to the console. You can view this by launching the Console application (in the Utilities folder), however, it's inconvenient to have to look in a separate window. Another alternative is to connect the process's stdout or stderr to the terminal device for GDB's Terminal window. Listing 9 shows how to do this.
Listing 9. Connecting stdout and stderr to GDB's terminal device.
(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's terminal. The function results should be 1 and 2; if not, something is horribly wrong. (gdb) call (int) open("/dev/ttyp1", 2, 0) = 1 (gdb) call (int) open("/dev/ttyp1", 2, 0) = 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 ...]
使用 Xcode 7.2 版和 iOS 9.2 等,我发现了以下作品:
- 关闭 phone 应用和手表应用
- Select Watch Extension Target 然后点击 Cmd+R (build and 运行)
- Select Phone 目标并按 Ctrl+Cmd+R(运行没有建筑)
在我的例子中,我在他们的模拟器中安装了这两个应用程序,并为这两个应用程序获取了 NSLog 输出。我不需要单独附加。希望这有帮助。
在我的例子中设置了自动查看NSLog,之前根本不显示
https://developer.apple.com/library/ios/qa/qa1747/_index.html
插入设备并打开Xcode
从菜单栏中选择 Window -> 设备
在左列的“设备”部分下,选择设备
要查看设备控制台,请单击右侧面板左下方的向上三角形
单击右下角的向下箭头将控制台另存为文件
当您的 Provisioning 配置文件设置为 Ad Hoc 或 Distribution 时 Xcode 不显示日志,您需要设置 development 才能查看日志
为了补充 Filipp Keks 的回答,这里有一个比公认的答案更简单的方法的直观表示。
来自 Filipp Keks 的回答:
插入设备并打开Xcode
从菜单栏中选择 Window -> 设备
在左列的“设备”部分下,选择设备
要查看设备控制台,请单击右侧面板左下方的向上三角形
单击右下角的向下箭头将控制台另存为文件
此屏幕截图是在设备 window 的 Xcode 7.3.1 中截取的。
我通过这个现已关闭的问题 (Xcode console empty after attaching to process) 来到这个问题。
我的问题是 Xcode 中的 调试控制台没有显示任何内容(只是一个空白框)。
我的解决方案是底部的一个小开关,它在“可变视图”和实际调试控制台之间切换。
这可能无法解决显示 NSLog 消息的问题,但在调试在后台启动的应用程序时可能会有所帮助。
您可以使用允许您记录消息的断点功能。 想法是:
- 创建断点并选中“评估操作后自动继续”
- 添加“日志消息”操作(您也可以使用表达式并打印出值,例如:“日志消息@variable@”)
- 使用预期的进程名称附加调试器(XCode 将等待进程启动)
- 触发应用启动。
致谢名单和详情: https://fluffy.es/how-to-debug-app-which-got-launched-push-notification/