DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Using programming tools

Using dbxtra

To debug testcase, use dbxtra. For testcase to be debugged, it must be compiled with the cc -g option specified. This option specifies that the compiler should include symbolic information in the binary. Compile testcase.c with debugging information using make:

make testcasedb

To initiate dbxtra issue the following command:

dbxtra testcasedb

The following dbxtra screen is displayed.

To begin debugging testcase, it must be run under dbxtra's control. To execute testcase within dbxtra, issue the dbxtra run command:

    (dbxtra) run -%
    This is a test
    So is% this
    %%
    %%
   <Ctrl>d
    execution completed
    (dbxtra)
In this example, we had testcase look for the argument %, which it failed to match in the second line, but did in the third.

The cp pointer points to the characters in the input buffer. Therefore, the cp pointer might be a place to start searching for the problem. Because we know the cp pointer is used in the PrintWords function from the cxref output, examining the function PrintWords, and monitoring cp, might lead us to discover why testcase is not behaving correctly. At this point, a breakpoint should be set in the PrintWords function. This allows control over the program's execution, enabling us to monitor the cp pointer. The following commands set a breakpoint and check to ensure that breakpoint has been set:

   (dbxtra) func PrintWords
   (dbxtra) stop at 22
   [1] stop at 22
   (dbxtra) status
   [1] stop at 22
   (dbxtra)

Notice the S beside line 25; this indicates that a breakpoint has been set.

The next action is to rerun the program with the breakpoint in effect:

   (dbxtra) rerun
   Running: testcasedb -%
   % a b c
   [1] stopped in PrintWords at line 25
   (dbxtra)
The where command displays the current location in the stack frame:
   (dbxtra) where
   PrintWords(wc = 4, match = '%'), line 25 in "testcase.c"
   main(argc = 2, argv = 0x7ffff81c, 0x7ffff828), line 87 in "testcase.c"
   (dbxtra)
The following two dbxtra commands display the type of variable (character) and what the match character is (%):
   (dbxtra) whatis match
   register char match;
   (dbxtra) print match
   `%'
   (dbxtra)
Because the breakpoint was set on line 25, the pointer cp has not been set yet. To execute the next step and set cp, enter next on the dbxtra command line. If the pointer cp is checked now:
   (dbxtra) next
   (dbxtra) print cp
   "%"
It displays the correct character. If one more line of code is executed, the cp pointer should display the same character:
   (dbxtra) next
   (dbxtra) print cp
   ""
   (dbxtra)
Notice that there is no value currently in cp. This may be the problem; it would seem that the cp pointer is being incremented even if a match is found. The result is that only double occurrences of the match variable character produces the correct behavior.

The next step in debugging testcase is to check if the problem assessment is correct. testcasedb needs to be rerun, and the cp pointer set:

   (dbxtra) rerun
   Running: testcasedb -%
   % a b c
   [1] stopped in PrintWords at line 25
   (dbxtra) next 2
   (dbxtra) print cp
   ""
   (dbxtra)
Notice the cp pointer is indicating a null character. The next step is to reset the cp pointer.

The assign command allows variable values to be changed. In this example, by subtracting 1 from cp, the correct character variable should be displayed.

   (dbxtra) assign cp = cp - 1
   (dbxtra) next
   (dbxtra) next
   %
   (dbxtra)
This indicates that the problem assessment was correct. The pointer was being incremented regardless of whether or not a match condition existed.

The last step is to delete the breakpoint and complete the program's execution:

   (dbxtra) cont
   [1] stopped in PrintWords at line 25
   (dbxtra) delete 1
   (dbxtra) cont
   <Ctrl>d
   execution completed
   (dbxtra) q

Correcting the code

To fix the problem within the testcase.c code, testcase.c must be checked out of SCCS, changed, recompiled, and retested. This ensures that the logic problem located through the debugger is the only problem with the code.

Check s.testcase out of SCCS:

   get -e s.testcase
SCCS responds with the following message:
   1.2
   new delta 1.3
   92 lines
Edit testcase.c by locating the following line in the PrintWords function:
   while((*cp) && (*cp++ != match))
   if (*cp == match) /* Found a match? Write the word on stdout. */
   		(void) printf("%s\n", Words[ix]); } return; }
Change the line to read as follows:
   while((*cp) && (*cp != match))
   		++cp;
   if (*cp == match) /*Found a match? Write the word on stdout. */
   	(void) printf("%s\n", Words[ix]); } return; }
Save the file, exit the editor, and check testcase back into SCCS:
   delta s.testcase.c
The new version of testcase.c now needs to be recompiled. Execute the makefile to ensure all compiling and linking steps are executed:
   make testcase

Next topic: Testing the correction
Previous topic: Debugging the code

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003