Command line application: How to attach a child process to xcode debugger?
Asked Answered
J

1

5

I'm currently making a command line app in C in which many child process is created. So I need to debug this children code. I have created a child process on Xcode as follow. (see the break point and running cursor.)

enter image description here

After executing some statements, I get xcode to attach GBN(885) to the xcode debugger as shown in below figure.

enter image description here enter image description here

It doesn't work. How can I attach the child process to xcode debugger? Thank you in advance.

Jacki answered 23/11, 2013 at 10:23 Comment(0)
J
5

Google and Apple developer page are really silent on this issue and finally I've found a good workaround. This error message appears when we get Xcode debugger to attach to the process that is a child process of process being debugged or that is a process already being debugged by Xcode debugger, gdb, or lldb.

error message

In order to avoid this irritating message, First put kill(0, SIGSTOP) statement where you want to stop the child process. In the following figure, I have put the kill statement right after the child is created.

enter image description here

Second, use gcc to compile your source codes with -g option.

$ ls
GBN.1  gbn.c  gbn.h  type.h util.c util.h
$ gcc *.c -g
$ ./a.out

[1]+  Stopped                 ./a.out
$ ps -ef | grep a.out
  501   628   600   0  9:33AM ttys000    0:00.00 ./a.out
  501   629   628   0  9:33AM ttys000    0:00.00 ./a.out

Now, all we have to do is to tell Xcode debugger to attach to the process by pid. Click the Debug menu and then find the Attach to process option to click By Process Identifier (PID) or name option. Then type the pid for child process (or parent process) and click attach button.

enter image description here

Enjoy Debugging!

enter image description here

Jacki answered 25/11, 2013 at 0:52 Comment(2)
Wonderful. I never would have figured this out myself.Cargian
Calling this a "good" workaround is reallllly stretching the definition of "good". We've got a rather large service written in Swift, with external dependencies, not some two-C-files demo program that just fork()s. Putting a SIGSTOP into the debuggee is not a complete non-starter but is a real pain when we're trying to debug shipping code. Also, this won't help debug crashes due to race conditions where the child does something before the parent is ready; by the time the child resumes the race will be long since over.Prominent

© 2022 - 2024 — McMap. All rights reserved.