Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

CS216: Introduction to Software Engineering Techniques (Fall, 2017) Lab Assignme

ID: 3889391 • Letter: C

Question

CS216:

Introduction

to

Software

Engineering

Techniques

(Fall,

2017)

Lab

Assignment

4

(20

points)

Today’s Date: Tuesday, September 19

Due

Date:

Friday,

September

22

The purpose of this lab assignment is

• Learning how to use GNU Debugger (gdb) in the

detection and correction of errors in a C++

program.

• Learning how to use valgrind to check whether the

memory management contains problems.

Problem:

1. In the terminal window, make the CS216 directory,

which you created in Lab1, your current working

directory.

2. Create a directory underneath the CS216 directory named Lab4, and make the Lab4

directory, your current working directory.

3. Without opening a browser, use command curl to download a zip file named

lab4source.zip from the link (http://www.cs.uky.edu/~yipike/CS216/lab4source.zip)

and save the file into your current working directory ~/CS216/Lab4 (Note the following

is on one line when you type the command):

$ curl –O http://www.cs.uky.edu/~yipike/CS216/lab4source.zip

4. Unzip the file you downloaded from step 3 using the command:

$ unzip lab4source.zip

It contains three files: main.cpp, BoxList.cpp and BoxList.h. Please note that DO NOT

modify any file until you finish step 7 in this document. Compile two source files using

the command:

$ g++ -g –o Lab4 main.cpp BoxList.cpp

Lucky the Leprechaun (shown in the picture above) is using this program to sort out his

Cereal Boxes. But it turns out he is not much of a programmer. There are bugs. This

program should help Lucky the Leprechaun (Sir Charms) to put his collection of cereal

boxes in decreasing order (or more precise, in non-ascending order if you consider the

equal ones) by the number of marshmallows, since the marshmallows represent Lucky’s

magic charms, each with their own special meaning of power. And the program should also

allow Lucky to add new boxes in his collection or remove boxes from his collection, but

the order should always be maintained. Can you help him fix the bugs in his program? That

is the reason you use –g option to compile his program. Let us try to run the created

executable file named Lab4 first, and it displays on the screen:

This program demonstrates the collection of boxes for the

leprechaun, Lucky.

Initially, we will create a box list collection as a present for

Lucky.

Then the user can manipulate the collection by adding new boxes or

removing existing boxes.

The Lucky Charms collection for Lucky the Leprechaun are in order:

The Lucky Charm Box No.1 contains 0 marshmallows.

The Lucky Charm Box No.2 contains 0 marshmallows.

The Lucky Charm Box No.3 contains 0 marshmallows.

*******************************************************

i: Insert a new cereal box in the collection

d: Delete an existing box (if the box does not exist, do nothing)

p: Print the boxes in the collection

q: Quit the program

*******************************************************

Please enter your choice here:i

Please enter the number of marshmallows in the box to insert:84

Segmentation fault (core dumped)

5. It seems the program has some problems to be fixed. To debug segmentation fault, first

use valgrind to check the possible memory problems and give you the helpful information

of the line number of which may cause the problems:

$ valgrind ./Lab4

It generates the following information:

==19246==

Conditional

jump

or

move

depends

on

uninitialised

value(s)

==19246==

at

0x4012DE:

BoxList::insertBox(Box)

(BoxList.cpp:88)

==19246==

by

0x401867:

main

(main.cpp:63)

==19246==

==19246==

Use

of

uninitialised

value

of

size

8

==19246==

at

0x40133D:

BoxList::insertBox(Box)

(BoxList.cpp:94)

==19246==

by

0x401867:

main

(main.cpp:63)

==19246==

==19246==

Invalid

write

of

size

4

==19246==

at

0x40133D:

BoxList::insertBox(Box)

(BoxList.cpp:94)

==19246==

by

0x401867:

main

(main.cpp:63)

==19246==

Address

0x5ab758c

is

28

bytes

after

a

block

of

size

32

in

arena

"client"

-°©-°©output

omitted—

==19246==

LEAK

SUMMARY:

==19246==

definitely

lost:

12

bytes

in

1

blocks

-°©-°©output

omitted—

Note that the number you see may be different as shown above (for example, 19246). Try

to explain why it generates “Use of uninitialized value of size 8 “ and “Invalid write of

size 4”. If you cannot explain by reading BoxList.cpp only, then we need the help from

the debugger.

6. Run the program under the gdb debugger.

$ gdb ./Lab4

gdb waits for commands. Get familiar with setting breakpoints, and looking at data,

stepping in/out, etc. Breakpoints can be set on a line number, or on a function in any file.

After starting Lab4 with gdb, but before running it (with the run command), you can set

breakpoints.

To set a breakpoint on any line in main.cpp:

(gdb) break linenum (use the line number from the source code)

Set breakpoints on line 38, 40 and 44, which can allow you to check the value of

marshmallowCount, calling member functions insertBox() and print() of the

BoxList class. Type run (or simply type r) to start running the program. When you

reach the breakpoint you can look at variables in main.cpp, and set other breakpoints.

When you run the program it will stop when you hit the breakpoint. You can now list the

source code where you are currently:

(gdb) list

Execute the next statement, step over function calls:

(gdb) n

Execute the next statement, step into function calls:

(gdb) s

Continue executing the program until the next breakpoint or an error occurred:

(gdb) c

Examine variables:

(gdb) p variablename

For example, you can use p marshmallowCount to check the value of marshmallows

generated by the random number generator on line 38 (Note you can see the value stored at

the variable marshmallowCount after executing the statement on line 38). Then step

into the function call of insertBox() on line 40 to check if it potentially contains

problems. Set up another breakpoint at line number 94, since it is the line number reported

from step 5 while running valgrind. Click “c” to continue running to the breakpoint at line

94, now you can check the values of num_of_boxes, capacity and see if they store the

value you are expecting. You can also check the dereference of boxlist_ptr, and see if it

points to the valid object of BoxList class. If you see the problem, try to explain. Then use

p index to check the current value of index, is that a right value? After executing the

statement on line 94, use p newbox and p *boxlist_ptr, do you see the difference?

Should boxlist_ptr point to newbox since newbox is the first object inserted into the list?

Suspicious! It tells why it generates “Use of uninitialised value“ and “Invalid write”.

7. Practice some other commands you learn from lecture notes. For example you can type

command s to step into the function call. You can look at the data values of some variables

inside this function, and continue typing n to go to the next statement inside the function.

When you type c to continue running the program, you may not be able to reach the next

breakpoint, and instead you will meet the segmentation fault, copy the information about

which line and which member function in BoxList.cpp causes this fault, paste into a file

named Lab4Debugging.txt, then use the command:

(gdb) up

to find the corresponding line number in main.cpp which causes this fault, and copy-paste

into the same file, Lab4Debugging.txt.

Here is an example content of Lab4Debugging.txt (the instructor replaces the certain

information with question marks, and your gdb should report the complete information.

Note part of the report may not be the same as this example, e.g., the memory address)

Program received signal SIGSEGV, Segmentation fault.

0x000000000040133d in BoxList::[???corresponding function]

(0x7fffffffe420, newbox=...) at BoxList.cpp:???

??? [??? Corresponding statement]

(gdb) up

#1 0x0000000000401868 in main () at main.cpp:???

??? [??? Corresponding statement]

Then also put your answer to the question “why does it generate ‘Use of uninitialised

value of size 8’ and ‘Invalid write of size 4’?” to the Lab4Debugging.txt, (Hint: you

can use sizeof() function to check how many bytes of a variable are in the memory

space, for example by calling sizeof(index) you can see the integer variable occupies

4 bytes in memory in your 64-bit Virtual Machine), and then you are done with writing this

file.

To quit gdb:

(gdb) quit

8. Based on the errors you found at step 7, open the source file BoxList.cpp in an editor,

try to fix the problem(s). Any ideas what caused the segmentation fault? (Hints: there are

problems in member functions InsertBox() and DeleteBox(). Also think about

how to apply shifting operations for inserting a box and deleting a box respectively to avoid

overwriting existing data.) Fix the problems of the function InsertBox() first, and

compile the source code, then use the gdb again to check the potential problems from

deleting a Box. It can help you find and fix the problems of the function DeleteBox() ,

and compile and run the program with gdb tool again until you fix all problems in both

insertBox() and deleteBox() of the BoxList class. DO NOT modify main.cpp

and BoxList.h for this Lab assignment.

The following are the list of testing cases which can help you test your program:

• Insert a Box to the beginning of the list;

• Insert a Box to the middle of the list;

• Insert a Box to the end of the list;

• Insert a Box to an empty list; (this can be done after deleting all Boxs from the

original list)

• Insert a Box which contains the same number of marshmallows as the Box already

in the list;

• Delete the first Box from the list;

• Delete the Box in the middle of the list;

• Delete the Box from the end of the list;

• Delete a Box which does not exist in the list;

• Delete the last Box from the list, then the list becomes an empty list;

• Delete from an empty list;

• Generate your own testing cases, great!

9. Then zip together: Lab4Debugging.txt, main.cpp, BoxList.cpp, BoxList.h using the

command:

$ zip Lab4.zip Lab4Debugging.txt *.cpp *.h

(or list the individual files)

Submission

Open the link to Canvas LMS (https://uk.instructure.com/), and log in to your account

using your linkblue user id and password. Please submit your file (Lab4.zip) through the

submission link for “Lab4”.

Grading (20 points + Bonus 3 points)

1. Attend the lab session or have a documented excused absence. (5 points)

2. Your modified program helps Lucky solves his problem. (15 points)

• fix errors in member function insertBox( ) of BoxList.cpp

(6 points)

• fix errors in member function deleteBox( ) of BoxList.cpp

(6 points)

• generate the debugging report which contains line numbers for the

segmentation fault. (2 points)

• the debugging report contains the answer to the question from valgrind.

(1 points)

Bonus: Demonstrate your program to your TA and answer TA’s questions. (3 points)

(Late assignment will be reduced 10% for each day that is late. The assignment

will not be graded (you will receive zero) if it is more than 3 days late. Note that

a weekend counts just as regular days. For example, if an assignment is due

Friday and is turned in Monday, it is 3 days late. )

Explanation / Answer

ASM_Address: 256 (RF180C Input area is set to 256-259 in the hardware config & Output area is the same)

ASM_channel: 1

command_DB_number: 47 if I remember correctly, I had manually set the command database number to this exact number so it should be right

command_DB_address: 0

MDS_control: 1 (I've tried the ANZ presence mode on true and false, no change)

RESET_long: true

MOBY_mode: B#16#5 (MOBY U / D / RF200 / RF300 / RF600 standard addressing)

scanning_time: 0

option_1: 0

multitag: B#16#1