Xcode附加到进程不显示NSLog [英] Xcode attach to process doesn't display NSLog
问题描述
我刚开始使用Apple Watch。在获取iOS应用程序时，我找到了
Apple在技术说明TN2239：iOS中确认（至少对于GDB）调试魔术。
控制台输出
许多程序，实际上是很多系统框架，打印调试
消息给stderr。此输出的目标最终是由程序控制的
：它可以将stderr重定向到它选择的任何
目的地。但是，在大多数情况下，程序不会重定向stderr
，因此输出将转到程序从其启动环境继承的默认目标
。这是
，通常是以下之一：
- 如果启动GUI应用程序，因为它将由正常的$ b启动$ b用户，系统将stderr上打印的任何消息重定向到
系统日志。您可以使用之前描述的
技术查看这些消息。
- 如果您在Xcode中运行程序，您可以在Xcode的调试器控制台窗口中看到它的
stderr输出（从Run菜单中选择Console
菜单项看到这个窗口）。
附加到
正在运行的程序（使用Xcode的Attach to Process菜单，或者附加
GDB中的命令）不会自动将程序的stderr连接到GDB窗口的
。你可以使用查看stdout和stderr附加后部分中描述的技巧
在GDB中执行此操作。
技术说明TN2030，'GDB for MacsBug退伍军人'。
上述TN2030在他们的服务器上不再可用（ 镜像 ）。它展示了如何将stdout和stderr重定向到Xcode控制台。但是，由于 shell tty 不是LLDB的有效命令，因此无济于事。但也许有一种不同的方式来访问tty Xcodes控制台使用，所以我附上了TN的重要部分。
在附加后看到stdout和stderr
如果将GDB附加到进程（而不是从GDB中启动进程
），您将无法看到
进程打印到stdout或stderr的任何内容。 Finder推出的程序通常
将stdout和stderr连接到/ dev / console，因此打印的信息
将进入控制台。你可以通过启动
控制台应用程序（在Utilities文件夹中）查看这个，但是，
不方便必须在单独的窗口中查看。另一个替代
是将进程的stdout或stderr连接到终端设备
，用于GDB的终端窗口。清单9显示了如何执行此操作。
清单9.将stdout和stderr连接到GDB的终端设备。
（gdb）attach 795
[...输出省略...]
（gdb）调用（void）DebugPrintMenuList（）
无输出） - ：
关闭stdout和stderr文件描述符。
（gdb）call（void）close（1）
（gdb）call（void）close（2）
确定GDB本身的终端设备的名称。
（gdb）shell tty
/ dev / ttyp1
重新打开stdout和stderr，但连接到GDB的终端。
函数结果应为1和2;如果没有，
是非常错误的。
（gdb）call（int）open（/ dev / ttyp1，2,0）
$ 1 = 1
（gdb）call（int）open（/ dev / ttyp1 ，2，0）
$ 2 = 2
再次尝试DebugPrintMenuList。
（gdb）call（void）DebugPrintMenuList（）
Yay输出！
Index MenuRef ID Title
----- ---------- ---- -----
< regular menus>
00001 0x767725D3 -21629 Ed
00002 0x76772627 1128< Apple>
00003 0x767726CF 1129文件
00004 0x76772567 1130编辑
[...剩余输出省略...]
I'm just getting started with Apple Watch. I found instructions from "Five Minute Watchkit", on getting the iOS app and the watch kit app both running in the simulator and both processes attached to the LLDB debugger.
What I do is launch and quit the iOS app to install a current version in the sim. Then I switch to the watchKit scheme and launch that, which displays my watch app UI on the watch simulator.
I then launch the corresponding iOS app in the simulator, then user "attach to process" in the Xcode menu to attach the debugger to the running iOS app.
This works. I can set breakpoints in either the watch kit InterfaceController or in my iOS app and the debugger breaks there when it should.
However, I'm not seeing NSLog() statements in the debug console from my iOS app. (I do see log statements from the WatchKit extension code.) If I set a breakpoint in my iOS app, it does stop at that breakpoint when it should. I assume the lack of console output from NSLog has SOMETHING to do with attaching to a running process on the sim rather than launching it from Xcode, but I don't know what that something is.
(BTW, attaching an action to a breakpoint that invokes NSLog from the breakpoint also doesn't display, but the "log message" debugger command DOES display. Does anybody have any insights?)
EDIT: The code in the iOS app doesn't seem to matter. In my case, it was a dirt simple IBAction that was attached to a button in the iOS app storyboard:
- (IBAction)buttonAction:(UIButton *)sender;
{
NSLog(@"Button clicked on iPhone");
}
I can set a breakpoint on that NSLog statement. The debugger stops at that line, but I don't see the log statement in the debug console.
I can reproduce that with a simple test app, sans WatchKit. The app consists of a NSTimer that prints "Timer fired" every second. (This code is 100% correct ;). Nothing shows in the log after I have manually attached to the process.
As far as I know NSLog outputs to stderr, I guess attaching the debugger does not redirect stderr to the Xcode terminal.
If you are okay with using the console app or the terminal to look at your logs you can do that. iOS8 stores simulator logs in ~/Library/Logs/CoreSimulator/<Device-UUID>. In this directory you will find a system.log, which contains all your NSLog output.
You can look at it in terminal (cat, grep, tail), or open it in the Console.app.
Apple confirms that (at least for GDB) in Technical Note TN2239: iOS Debugging Magic.
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'.
The mentioned TN2030 is no longer available on their server (mirror). It showed how you can redirect stdout and stderr to the Xcode console. However, since shell tty isn't a valid command for LLDB it won't help much. But maybe there is a different way to access the tty Xcodes console uses, so I attach the important part of that 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 = 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 ...]
这篇关于Xcode附加到进程不显示NSLog的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
