Lab Assignment #4 - Eclipse Debugger - WPI



Lab 4 (10 points) November 20, 2013120650CS-2301, System Programming for Non-majors, B-term 201300CS-2301, System Programming for Non-majors, B-term 2013Laboratory Assignment #4 —Debugging in Eclipse CDT Due: at 11:59 pm on the day of your lab sessionObjectiveTo learn to learn to use the Eclipse C/C++ debugger.IntroductionOne of the most powerful aspects of an Integrated Development Environment is the availability of a debugger integrated with the graphical user interface. This makes the “edit-compile-debug” loop very easy and quick. Moreover, you can easily set breakpoints and get a good look at what your program is doing.Eclipse CDT includes a graphical interface to gdb, the GNU Debugger, which is one of the most powerful and flexible in the C/C++ development world.In this Laboratory Assignment, you will learn how to use the basic debugging features of Eclipse.Getting StartedSign the attendance sheet. Create a directory to hold the files for Lab 4. Download and unzip the set of files at the following URL:– directory should now contain a makefile and a single source code file Sample.c.Start Eclipse and create a new C project containing copies of these two files. Build the project, and set up the launch configuration with the following arguments:–9 8 7 6 5 4 3 2 1 0This program simply reads its arguments from the command line, sorts them using a well-known sorting algorithm called Shell Sort, and prints them in order on the standard output.Build and run the project. If it works properly, it should print the line0 1 2 3 4 5 6 7 8 9Run it several more times. Vary the number of arguments and their values and convince yourself that it is still running properly. (You can run the program with different arguments simply by selecting Run Configurations… from the Run menu, and then by selecting the Arguments tab. Enter the arguments you want and click on the Run button. The results will be displayed in the Console tab at the bottom of the Eclipse window.This program has a bug in it — a rookie error that may be hard to spot and that may or may not show itself. It is possible that you could run many tests and never see the results of the bug, or you may have already seen it. A test case that sometimes brings out the bug is one of the following sets of arguments:–100000000 9 8 7 6 5 4 3 2 1 0 100000000 8 7 6 5 4 3 2 1 0Another way to bring out the bug is to run the program Lab4_Sample from a Windows command prompt. Click Start > Accessories > Command Prompt. Navigate to your workspace and to this project within that workspace. Run the program from the command prompt with various sets of arguments.A third, more reliable, way to bring out the bug is to export the project to a CCC Linux system (or to any other Linux system). Build the program with the makefile and run it with a several argument lists. In some cases, it will run correctly, but in some cases the output is sorted and contains the right number of results, but at least one of the inputs is replaced by a bogus number. In a few cases, the program gets a segmentation fault or other fatal error.DebuggingTo debug your program in Eclipse, make sure that it was built with the –g switch. This tells the compiler to include extra information in the object file so that a debugger can find its way around the compiled code.Open the project file Sample.c in a source code tab. Notice that this program has two functions — shell_sort() and main(). Right click at the extreme left margin of the source code to bring up a menu. Select Show line numbers to cause line numbers to display in this tab.Next, set a breakpoint where the variable a is initialized in main() — i.e., line 31. To set the breakpoint, right click again in the left margin and select Toggle Breakpoint. A tiny blue dot will appear next to the line number. This tells the debugger to suspend execution when it reaches this point in the program — before executing the code on that line.Start the debugger and simultaneously load the program to run in debugging mode by invoking the Debug Configurations… command under the Run menu. Eclipse now switches to the Debug perspective. In this arrangement of windows, there is a Debug tab in the upper left corner, a group of four tabs in the upper right (i.e., Variables, Breakpoints, Registers, and Modules), a group of tabs in the left middle containing your open source code tabs, a tab on the right called Outline, and a group of console tabs at the bottom. A picture of the Debug perspective is shown in REF _Ref358641271 \h Figure 1 REF _Ref358641271 \p \h below.At the top of the Debug perspective, just below the menu bar, is a row of icons that control some of the most common debugging commands. This is shown in REF _Ref362956116 \h Figure 2, which is a magnified view of the top of REF _Ref358641271 \h Figure 1. Note that some of the icons are very faint. Hover the cursor over each icon to see its name.Figure 1center000Figure 2At this point, the debugger has “paused” your program before it executes its first instruction — i.e., before the first executable line in main(), which happens to be where you set the breakpoint.In the left margin of the code of the Sample.c tab will be a small green arrow indicating the point of execution. In the upper right window, the Variables tab shows the names and values of the variables in the current scope at the point of execution. As you can see, argc contains the number of arguments that you supplied to the program (including the program name itself) and argv is a pointer. Both a and i have garbage values because they have not yet been initialized.You can also hover over an instance of any variable in the code, and a popup box will appear with the value of that variable. This also works for expressions. For example, select the expression argc – 1in the argument list of the call to malloc() on line 31. Now, hover over this expression, to bring up the popup box shown in REF _Ref362958003 \h Figure 3. In this case, the value is 12, because the program had been called with thirteen arguments.center000Figure 3Three very useful debugger commands are Step into, Step over, and Step out, represented by the three yellow arrows just below the Search menu item in REF _Ref362956116 \h Figure 2. Click on Step over. You will see that the point of execution has advanced to line 32 and that the variable a now has a valid pointer value.Click on Step over twice more to enter the loop that initializes the array a. Examine the values of the argument of atoi (i.e., argv[i+1]) and the resulting assignment to the array element a[i]. They should be the same value, and that value should be the value of the first argument on your list in the Run Configurations… or Debug Configurations… menu command.Next, set a breakpoint on line 35, the call to the shell_sort() function. Click the Resume button (i.e., ). The program will finish the for-loop and suspend execution just prior to the call to shell_sort(). To see what the arguments to shell_sort are, go to the Variables tab in the upper-right window. So far, the debugger thinks that a is a pointer. However, you know that it is an array. To see the values of the array, right-click on the name a (in the Variables tab) and select Display as Array…. A new dialog box pops up asking you to enter the starting index and the length of the array. Enter zero for the starting index, and enter the value of argc for the length, because this is what the program supplied to shell_sort() on line 35.Click on the small arrow to the left of a in the Variables tab. This will expand a and show you the values of the individual elements of a. In addition, you can click on the line representing a itself, and in the lower panel of the Variables tab, it will show the entire array. REF _Ref363056895 \h Figure 4 REF _Ref363056895 \p \h below shows an example.Now the problem becomes apparent:– there are one too many values in the array a, and the last value is a garbage value. The shell_sort() function correctly sorts this (erroneous) list and puts the garbage value in numerical order along with the rest of the array, and then the for-loop of lines 37-39 prints out the sorted array, but of the correct length. There are several possibilities:–The garbage value is larger than any of your input values. In this case, it sorts to its original position at the end of the extended array, the print loop prints out the sorted array (not including the garbage value), and the program appears to work correctly.The garbage value is smaller than at least one of your input values. In this case, it sorts into the appropriate place in the array, and the largest of your input values is left off the end of the output. Also, the largest value does no damage to anything else, so the program appears to work correctly.Figure SEQ Figure \* ARABIC 4The nastiest case is that garbage value is smaller than at least one element of the array, and the largest of your inputs overwrites some crucial data that just happens to be stored at the end of the array. This crucial data could be control information for malloc(), which in many implementations is stored between the allocated storage. If this control information is overwritten in a damaging way, malloc() could go haywire, perhaps causing a segmentation fault.Because of these three possibilities, the error may or may not have made itself known when you were testing your program from a command prompt or a Linux shell.If you now click the Resume button and let the program run to completion, the debugger will discover that The Heap has been corrupted and exit with the following warning:–warning: HEAP[Lab4_Sample.exe]:warning: Heap block at 005118B0 modified at 005118E8 past requested size of 30To finish this part of the lab, fix the “error” in the program, rebuild the project, and convince yourself that it works correctly and completes without any warnings that the Heap has been corrupted. In particular, show that the value beyond the end of the array is not corrupted.Getting Credit for this LabTo get full credit for this lab, you need to capture two screenshots of your array in Programming Assignment #4. Capture one screenshot of the array immediately before your program sorts it, and capture another screenshot immediately after your program sorts it. Note: An easy way to capture a screenshot of any tab in Eclipse is to do the following:– (a) Drag the tab from its place in the Eclipse window to the desktop. It now becomes an independent window on the desktop. (b) Press ALT-PrintScreen on the keyboard to make a copy of that window. (c) Paste that copy into a document, which you can later submit. (d) Invoke the Reset Perspective… command from the Window menu to return the tab to its original place in the Eclipse window.Once you have captured both screenshots, submit them to the web-based Turnin system at assignment is Lab 4.Quick Reference Guide — Debug view toolbar optionsThe table below is copied from the Eclipse CDT help system. It lists the toolbar icons displayed in the Debug view. Note that breakpoints supersede the Step Over and Step Out commands. This means that if you attempt to step over a function call, and if that function contains a breakpoint, the breakpoint will be taken. Likewise, if you attempt to step out of a function in order to return to its caller, and if that function encounters a breakpoint, that breakpoint will be taken.IconsActionDescriptionRemove All Terminated Launches Clears all terminated processes in Debug view? Connect to a ProcessEnables the selection of a running process to debug.RestartStarts a new debug session for the selected processResumeSelect the Resume command to resume execution of the currently suspended debug target.SuspendSelect the Suspend command to halt execution of the currently selected thread in a debug target.Terminate Ends the selected debug session and/or process. The impact of this action depends on the type of the item selected in the Debug view.DisconnectDetaches the debugger from the selected process (useful for debugging attached processes).Step Into Select to execute the current line, including any routines, and proceed to the next statement.Step Over Select to execute the current line, following execution inside a routine.Step Return Select to continue execution to the end of the current routine, then follow execution to the routine's caller.Drop to Frame Select the Drop to Frame command to re-enter the selected stack frame in the Debug view.Instruction Stepping Mode Activate to enable instruction stepping mode to examine a program as it steps into disassembled code. Use Step Filters Select the Use Step Filters command to change whether step filters should be used in the Debug view.MenuUse the Debug view menu to:change the layout of debug view (tree vs. breadcrumb)alternate showing of full or no paths on source filescontrol how views are managedactivate or deactivate the child elements shown in the Debug view ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download