CSCI
1300 Debugging Contest
In this exercise you'll be thinking about bugs, and, more importantly, you'll get some experience in finding difficult bugs in a program. The exercise requires a number of steps that have to be coordinated with other people in the class, so follow closely:
In class on Monday:
1. Form a team of from 3 to 5 classmates. You'll have some time in class to work with your team, so it is not essential that your schedules are compatible. Clayton will assign a number to each team.
2. Choose one member of your team to be Captain.
3. If you are team n, get the email address of the Captain of team n+1. (If you are the highest numbered team, get the email address of the Captain of team 0.)
4. During class on Monday, you'll be inserting bugs into the example program that's included at the end of these notes.
Here are the rules:
R1. All bugs must have visible symptoms. That is, it must be obvious that the behavior of the bugged program is not normal, if any of the bugs have not been fixed. "Obvious" means that the bad behavior will show up on any ordinary image, and can be plainly seen, or is otherwise unmistakable, like a crash at runtime.
R2. You can make changes in no more than four places in the program. A change consists of (possibly) removing some code and (possibly) putting in some code at a single place in the program.
Note: If you want to introduce bugs that prevent the program from compiling, or that produce compiler errors or warnings, you can, but these are usually easier to find and fix than bugs that compile fine but do not run properly.
5. Email the bugged program to the team whose email address you got in Step 3.
By the end of class Wednesday:
8. Work with your team to find and fix the bugs in the program you were sent. There are rules for this activity, too:
R3. You can work on debugging your program as soon as you get it, that is, you do not have to wait for Wednesday's class. BUT you must keep track of any time anyone on the team spends on debugging.
R4. You CANNOT compare the bugged version of your program with the original.
See the notes below for suggestions on how to approach the debugging process.
At the end of class on Wednesday, or on the following day, we'll compare debugging times for the teams. There will be worthless prizes in more or less the following categories:
for placing the bugs that took longest to find and fix
for being the team that debugged their program the fastest
for placing the most interesting bug (even if it wasn't the hardest to find)
The Psychology and Strategy of Debugging
Your mind is organized to make sense out of poor quality, poorly perceived, and poorly organized input. This hurts you badly during debugging, because you tend to read code in such a way that you see what it should say, rather than what it actually says. Because the compiler has not even an approximation to a human mind, it processes code strictly according to what it actually says, and so (of course) what the program actually does is dictated by what the code actually says, not what it should say.
The key way to protect yourself against this problem is to spend only limited time studying your code, before making the program tell you what it is actually doing, by adding printouts. You'll be amazed at how often you are sure a bug can't be in a certain place, because you are sure that part of the program is working properly, and then a printout tells you the problem is right in the middle of the part of the code that "can't be wrong".
Strategy: When you put printouts into the code you are debugging, try to do this in such a way that you can narrow down where the problems are. Is something going wrong in the first half of the program, or the second half? If it's the first half, is it the first quarter or the second quarter?
Another bit of psychology is that you tend to get stuck on certain ideas about what can and can't be happening in your code. If you have been sweating over a bug for an hour without success, stop and do something else for a while. When you get back to it there's a good chance you will see something you have been missing, or try a possibility you were ignoring.
Related to the last point is that debugging requires alertness. The stereotype of the programmer pulling an all-nighter to fix code is a bum steer. You get good work much more easily from a rested mind.
Example program
into which you will insert bugs (this program is the one described in Notes 6):
#include
<stdio.h>
void piglatin(char input[],char output[]);
int isvowel(char c);
void stripfirst(char input[],char
output[]);
void addletter(char input[],char c,char output[]);
int main()
{
char input[100];
char output[100];
FILE *fp;
fp=fopen("piglatintest.txt","r");
if(!fp)
{
printf("gosh!");
return 1;
}
while(fscanf(fp,"%s",input)==1)
{
piglatin(input,output);
printf(" result is <%s>\n",output);
}
return 0;
}
void piglatin(char input[],char output[])
{
char first;
first=input[0];
if(isvowel(first))
{
addletter(input,'w',output);
addletter(output,'a',output);
addletter(output,'y',output);
return;
}
stripfirst(input,output);
addletter(output,first,output);
addletter(output,'a',output);
addletter(output,'y',output);
return;
}
int isvowel(char c)
{
if((c=='a')||(c=='e')||(c=='i')||(c=='o')||(c=='u'))
return 1;
return 0;
}
void stripfirst(char input[],char
output[])
{
int
i;
for(i=1;i<strlen(input);i++)
output[i-1]=input[i];
output[strlen(input)-1]='\0';
return;
}
void addletter(char input[],char c,char output[])
{
int
i,n;
n=strlen(input);
for(i=0;i<n;i++)
output[i]=input[i];
output[n]=c;
output[n+1]='\0';
}