Debugging programs with fork

[Chris Torek]

>In article <13819 at mimsy.UUCP> I wrote:
>>... the existing Unix debuggers cannot handle programs
>>that fork.  SunOS 4.0 provides new facilities that make it possible,
>>but if you are dealing with older Unixes, you must either delete the
>>fork, or fall back on more `traditional' debugging schemes.

In article <175 at csd-v.UUCP> bak at csd-v.UUCP (Bruce A. Kern) writes:
>I'm not sure what Chris here means by 'traditional' schemes (print
>statements, etc.?).

Actually, I prefer *thinking* :-) about the bug (it *does* have a
remarkable success rate%).  But being able to inspect the state, and in
particular the call stack, of a process is handy.

Several people have asked what the new facilities are.  I do not know;
but I do know that something new exists.  (Apparently dbx acquired an
`attach' command.  SunOS 3.2 dbx does not have this command.)
-----
% For me, at any rate.  I find that any time I am `thrashing' with
some particular bug, it helps to stop, see what data look like
when they are wrong, see which procedures modify those data, and
then decide what assertions should be made about the data in each
place.  It usually becomes obvious just which assertions are false.
Of course, the fix may still not be obvious. . . .
-----
>In the case where a executable is execed after the fork, I've had success
>by relpacing the execed program with an execed debugger ....

A nice trick.

Under 4BSD, you can also stop the child process and use `gcore' to get
a core image, which you can then inspect with dbx.  (You can use gcore
on a running process, but you will get inconsistent data.)  Stopping
is rather hit-or-miss unless you change the child code itself, however.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris