Auto attach to every child process spawned by the app beeng debugg

Auto attach to every child process spawned by the app beeng debugg

Post by TWVqZWR » Fri, 13 Apr 2007 19:08:00


Hi!
I want Visual Studio de *** to attach automaticly (and silently) to every
child process spawned by the app beeng debugged. Does there exist any
settings in Visual Studio or may be a plugin that enables this feature?

Inet search doesn't reveal anything usefull unfortunately. The frequently
proposed solution is to place DebugBreak() in a source code of the child
process. Though source code modification is acceptable, the solution is not
very usable for me. With this approach you have to complete 2 dialogs - "the
program failed" and "choosing the de *** ". That is annoying. And the dialog
does not allow to choose the instance of Visual Studio where my solution is
opened and the de *** already runs. It is a severe limitation - the source
code of a child process is a part of the solution with breakpoints set up and
everything.

WBR, Mejedi
 
 
 

1. How do I: Main thread spawn child threads, which child processes... control those child processes?

2. How do I: Main thread spawn child threads, which child processes...control those child processes?

Jeff Rodriguez < XXXX@XXXXX.COM > writes:


Well, popen() uses fork and exec too. I would put it a different way,
and say that if the standard popen() doesn't meet your needs, you may
need to code a custom version that does what you want.


Why are you worrying about this? The only process on a Unix system
that isn't created by a fork/exec, is init. popen() uses fork/exec,
and so does system().


You need to decide whether bi-directional communication is a requirement.
If it is, then you should first determine whether the standard popen()
will support that. Some OS's (e.g. Solaris, FreeBSD) have pipes that allow
bi-directional communication, and others (e.g. Linux) don't.

If you need bi-directional communication, then you will definitely need to
do a custom popen(), since you will need separate pipes for the child process's
stdin and stdout.

If you wish to avoid threads and instead monitor multiple child processes
using select(), then there is another issue, which is that popen() provides
a buffered IO stream (FILE *) rather than a file descriptor. You will need
the file descriptor for select(). You can get the underlying file descriptor
using fileno(), and you can make it non-blocking for use with select() via
fcntl(). But you need to be very careful if you are mixing buffered IO
(fread, fscanf, etc. ) with select(), since select doesn't know whether
there is data in the buffer.

I would start with standard popen(), and see how far I got with that.
You may find that popen() doesn't provide any advantages compared to
system(), or you may find that you need to customize popen() for your
needs.

-SEan








3. How do I: Main thread spawn child threads, which child processes...control those child processes?

4. How do I: Main thread spawn child threads, which child processes... control those child processes?

5. How do I: Main thread spawn child threads, which child processes...control those child processes?

6. How do I: Main thread spawn child threads, which child processes...control those child processes?

7. service: cleaning up spawned unmananged process that spawns process

8. Using Expect to spawn a perl process which spawns another perl process

9. Capturing spawned child process's STDOUT & STDERR

10. Apache2 error - could' nt spawn child process

11. Using spawn() to capture output of child process

12. Spawn a child process in WSH or WMI

13. apply: Spawning child process: invalid argument