Lab 10: Debugging

Submit by Friday, Nov 20 at 11:59 PM

Table of Contents

Pre-lab

Decide if you'd like to use an IDE or not. See the introduction.

IDEs: An Overview

In the real world, it is very common for Java programmers to use an Integrated Development Environment or IDE. IDEs provide a number of handy features like real-time syntax checking, automatic code completion, refactoring tools (e.g. renaming variables, methods, or classes across an entire project), and a debugger.

The downside of using an IDE is that it does a lot of things magically that one really ought to know how to do from the command line, like compile files, run programs, I/O redirection, etc. Since the command line is the common communication channel used by every program, we felt it was important that you get a chance to work with it closely.

Furthermore IDEs can be quite complex compared with a text editor like Sublime, and it can be annoying to try to find the magic command that does what you want. IDEs also have persistent state

Separate command line tools vs. an IDE.

In this lab, you'll be debugging broken project 1 submissions from a previous semester using one of the following three recommended approaches (your choice):

  1. The Eclipse debugger
  2. gjdb from Emacs
  3. gjdb from the command line

The specification for that semester was somewhat different from this semester (here's the specification), as is the code base, but the basic ideas are the same. This is somewhat of an experiment to see how you get along when thrown into a strange program and asked to debug (a not uncommon event in the real world).

You are also welcome to use any other IDE (e.g. NetBeans, IntelliJ, jGrasp), but official support will not be provided for those IDEs. Note that NetBeans is (IMO) easier to figure out on your own. You're welcome to try.

Eclipse, NetBeans, and IntelliJ can also be used on your own machine for code editing, execution, and testing, even if you're on Windows, but official support by the course staff will not be provided. However, there will be two unofficial workshops on setting up Eclipse and Intellij on Wednesday November 5th in room 275 at 7-9 PM and 9-11 PM. These workshops will count as lab attendance for this week (so if you copy down the MWotD during these workshops, that's OK).

Picking an Environment

Your first step is to decide which approach to take. If you don't already have an opinion, I found Netbeans the easiest of the four options to figure out.

A brief summary is provided below. When you've chosen, click on the provided link to begin this lab in the environment of your choice. If you change your mind, you can always come back and try another one.

  1. The Eclipse debugger: The more 'real world' tool compared to Netbeans. The most popular IDE for Java. Somewhat less intuitive to figure out through experimentation than Netbeans.
  2. gjdb from the command line: If you want to stick to using separate simply but powerful tools (e.g. Sublime for editing, make for compiling, gjdb for debugging), this is a fine choice. We'll learn additional commands in this lab that will make gjdb more pleasant to use.
  3. gjdb from Emacs: If you like Emacs, this might be the option for you. If you haven't taken to Emacs yet, I don't recommend this option. The directions for this are very similar to the gjdb from the command line adventure, so separate instructions are not provided.

Bug 2

An important part of debugging is working with a simplest case that reproduces the error. This can either be a JUnit test or a simple system level test (in jump61 and in db61b, this would be a short list of commands that shows the error).

For this problem, pretend that your colleague has skipped town, leaving you only with a note that says: 

"Single table select causes exception. Example:

load enrolled2;
select SID from enrolled2 where CCN > '200';

Looking at his code, you'll see that he has written some JUnit tests (BasicTests.java). Run these tests and verify that they pass. If you're using Eclipse (or some other graphical IDE) you'll have to spend some time figuring out how to actually run the tests -- don't skip this step, as you'll want to know how to run UnitTest.java for project 2. If you're using the command line, you can just run "make bcheck" from the bugs/bug2 folder.

While we could try to write a JUnit reproducer, our colleague has already given us one in his note. Start up bugs.bug2.db61b.Main and run the test. To do this from the command line, run the following from the bugs/testing folder. 

$ java -cp ../:$CLASSPATH bugs.bug2.db61b.Main

If load enrolled2 doesn't work, make sure your classpath (if working from the command line) or your working directory (if working from within Eclipse) is set. Also that was three different uses of work in a single sentence. Fun.

Using what we learned earlier in this lab, find and fix the bug that is causing the exception (hint: it can be fixed in two (and maybe possible one... not sure) lines of code).

Even after you fix the exception, there's still a bug where duplicates are allowed, i.e. you'll see: 

$ java -cp ../:$CLASSPATH bugs.bug2.db61b.Main
DB61B System.  Version 2.0.
> load enrolled2;
Loaded enrolled2.db
> select SID where CCN < '200';
Error: unexpected token: '<'
> select SID from enrolled2 where CCN > '200';
Search Results:
 104
 104
 104
 104

This is a less interesting bug to identify and find and is therefore optional, but you're welome to fix it if you'd like.

Do not use print statements. If you do, you're defeating the point of this entire lab.

Submission

Submit your lab files including the corrected bugs.bug2.db61b package.

The folder must be named lab10.

While we are almost certain our commands won't mess up your files, you should not completely trust us. Always keep your own backups!