|
|
(void) execl("/usr/ccs/bin/get", "get", path, 0);
$ sget <files file1: 0 characters, 0 words, 0 lines main.c: 0 characters, 0 words, 0 lines $ wc -c main.c 6231 main.cThe bug must be after get(1) finishes or you would have seen the same error message you saw earlier.
debug> create sget <files New program sget (process p1) created HALTED p1 [main in sget.c] 132: (void)signal(SIGHUP,handler); debug> stop sget.c@64 EVENT [1] assigned
debug> runThe debugger displays the following:
file1: 0 characters, 0 words, 0 lines Process p1 forked; new process p2 now controlled
debug> release -p p2The debugger displays the following:
releasing and running p2
debug> signal -i sigcld debug> runThe debugger displays the following:
STOP EVENT TRIGGERED: sget.c@64 in p1 [get in sget.c] 64: if ((infile = fopen(newfile, "r")) == 0)
debug> stepThe debugger displays the following:
STEPPED p1 [get in sget.c] 70: while(fgets(buf, BUFSIZ, infile) == 0)The problem is the infamous backwards test; it should keep looping as long as fgets succeeds (i.e., returns a non-zero value).
When you released p2, you relinquished all control over it. If you had defined any events for it, they would be deleted. If it goes on to fork another process or exec another program, debug will not tell you about it, and it no longer shows up in the debugger's process list. You may release grabbed processes (release is the inverse operation of grab), processes created within the debugger, and threads.
When you create or grab a process and you are not
interested in any of the process's children,
you can avoid seeing them at all with the -f option
(for ``follow'') to the create and grab commands.
Typing -f none tells the debugger not to follow (control)
any of the process's children.
Typing -f all or -f procs tells the debugger
to follow all the children;
this is the default behavior.
Therefore, in
Session 7, you could have used this sequence of commands
to get to the offending function:
debug> create -f none sget <files New program sget (process p1) created debug> stop sget.c@64 EVENT [1] assigned debug> signal -i sigcld debug> run file1: 0 characters, 0 words, 0 lines STOP EVENT TRIGGERED: sget.c@64 in p1 [get in sget.c] 64: if ((infile = fopen(newfile, "r")) == 0)
Using the -f option affects only the processes in the individual create or grab command. You may change the default behavior for all instances of those commands by setting the debugger variable %follow to all, procs, or none. Unlike processes, you cannot tell the debugger not to follow threads, since the debugger must know about all the threads in a process to maintain the correct state information internally. You can, however, tell it that you do not want to know about a particular thread by releasing that thread. That thread will no longer show up in the ps output, and you will not be able to do anything with it, even though the debugger itself still knows about it.
You can also fine-tune the amount of information you see for the thread that you control by setting the debugger variable %thread_change appropriately. The default value of this variable is stop, which means the debugger will print a message and stop the thread whenever a thread: