Programming Principles and Practice Assignment
Lab 1 - Subversion (SVN) and General UNIX
Exercises -
1. Suppose you have a ?le called first_file.txt that contains the output of the command yes | head - n 10 and a file called second_file.txt that contains the output of seq 1 10
What single command (no pipes) could you use to combine the two files column by column, and output the result to stdout such that it looked like the following?
|
y
|
1
|
|
y
|
2
|
|
Y
|
3
|
|
Y
|
4
|
|
y
|
5
|
|
y
|
6
|
|
y
|
7
|
|
y
|
8
|
|
y
|
9
|
|
y
|
10
|
Give that command.
Hint: a command to take apart files by columns is cut(1). What is the opposite of "cut"?
2. Assuming that you saved the output of the command you wrote for question 1 to a file called my_output.txt, give a single sort(1) command (no pipes) that outputs the file's content sorted by the numbers in the second field in reverse. It should look like this.
|
y
|
10
|
|
y
|
9
|
|
Y
|
8
|
|
Y
|
7
|
|
y
|
6
|
|
y
|
5
|
|
y
|
4
|
|
y
|
3
|
|
y
|
2
|
|
y
|
1
|
3. In this question, you will practise using svn for version control. Place a log of all the commands used in this question, as well as the resulting output, in lab9.txt. Each student has a personal repository. Locate your "working copy" directory under your home directory.
As shown in class, one can make use of shell variables to reduce the amount of information that has to be typed in commands to svn. Also note that if you do not wish to provide the log message via a -m option to svn commands that want such a message, make sure to have the EDITOR environment variable defined to be a reasonable value before issuing the command.
Perform the following actions or tasks in the order specified.
(a) Use the "svn info" command to get information about your repository.
(b) Create a subdirectory in your repository for a new project called Lab09. Then within that new project directory, create subdirectories called trunk, branches, and tags. Make sure to provide informative log messages for each directory creation in the repository.
(c) Using the "svn list -R" command, get a listing of all the (files and) directories in your repository within the Lab09 project. If you wish you can use - -recursive rather than -R.
(d) Create a directory for your working copy of the software in the Lab09 software. Then change your current working directory to this new directory. Finally, using the "svn checkout" command, check out the current version of the trunk of the Lab09 project. That is, you will want to check out Lab09/trunk from your repository. Note that currently that trunk is empty.
(e) The previous command should have created a subdirectory called trunk in your current working directory. Change your current working directory to this subdirectory. Perform an ls command to demonstrate that the directory is, in fact, empty. Finally, using the echo command, create a file named file1.txt that contains the string "This is file 1".
(f) Perform an "svn add" command to inform svn that you intend to add file1.txt to the software in the repository. Then use ls and "svn list" commands to show that file1.txt is in the working copy directory but hasn't actually been copied into the repository.
(g) Using the "svn commit" command cause file1.txt to be "pushed" to the repository. Make sure to supply an informative log message to the commit operation. Then using an "svn list" command show that file1.txt is now present in the repository.
(h) Using the "svn status -v" command, show the status of the files in your current working directory. Then, create the ?le file2.txt using echo. Have the content of the file be the single line "This is file 2".
(i) Perform another "svn status -v" command. In your lab9.txt file comment on the meaning of the difference in status output at this step versus the previous step. What is the status output telling you? Place your answer in lab9.txt.
(j) Perform an "svn add" command to inform svn that you intend to add file2.txt to the software in the repository. Then perform another "svn status -v" command. Finally, comment on the meaning of the difference in status output at this step versus the previous step. What is the status output indicating to you? Place your answer in lab9.txt.
(k) Using the "svn commit" command cause file2.txt to be "pushed" to the repository. Make sure to provide an informative log message. Then perform another "svn status -v" command. Finally, comment on the meaning of the difference in status output at this step versus the previous step. Place your comment in lab9.txt.
(l) With the echo command add the sentence "This is the second line of file 1" to the end of file1.txt. Then perform another "svn status -v" command. Finally, comment on the meaning of the difference in status output at this step versus the previous step. Place your comment in lab9.txt.
(m) At this point the changes to file1.txt need to be committed to the repository. However, before doing this, it is good practice to do an "svn update" command first to make sure any changes to the repository are propagated to the working copy. Do this by invoking a "svn update" command. Finally commit the changes to file1.txt to the repository. Again make sure to provide a meaningful log message.
(n) Using "svn log" get a verbose log of the evolution of the content of the file file1.txt in the repository. Part of the mark for this question will be based on the informativeness and appropriateness of messages stored in the log.
(o) Perform a second "svn log" to again get a verbose log, but this time obtain it for the entire trunk of the Lab09 project in the repository. Again part of the mark for this question will be based on the informativeness and appropriateness of messages stored in the log.
Lab 10 - Makefiles and Interactive Debugging
Exercises -
1. This question involving Makefiles has several parts.
(a) Use the curl(1) command to download the source code for the factor program.
A bit of documentation for this program is available at this URL:
(b) Use a UNIX command to un-tar (unpack) the file you downloaded in part 1a. Then change your current directory to the factor subdirectory that was just created. Notice that the source code for factor is written in C.
(c) Use the make(1) command with appropriate options to print the commands that would be executed if you were to invoke make at this point (with no options or arguments). Do not actually run the makefile! It is always a good idea to do this before using someone else's makefile just to make sure it isn't going to do anything you are not expecting or would not approve of.
(d) You may have noticed that the output from step 1c showed a cc command involving the "-s" option. This option is deprecated, and should be removed from the set of LDFLAGS. Copy the original Makefile to Makefile.org. Then edit the Makefile to remove the use of the "-s" option. You do not need to submit a log of your editing. Finally, using diff(1) show the changes you made to the Makefile.
(e) Use make to build the factor program. Do not "make install". Test the factor program with arguments "987654321", "2.", and "101-105" to get an idea of the capabilities of the program and what its output looks like. Note that there may be another program called factor in the directories specified by your PATH; if so, you will need to explicitly specify the path to your newly-built factor (i.e. "./factor") in order to run it.
Feel free to test factor on more inputs. You may be using the factor program in a lab next week, so do not delete it at this time.
2. In question 3a, you will need to produce a core dump file. Whether or not a core dump file will be created for you depends on your resource limit settings. First use a "ulimit -a" or prlimit command to see the resource limits for your shell and any children it creates. If the limit for core file size is not unlimited, then use the "ulimit -c unlimited" command to set it to unlimited. Confirm the setting with a final "ulimit -a" or prlimit command.
For more information about resource allocation limits, see the man pages for prlimit(1) or getrlimit(2). Usage of ulimit is described in the relevant section of the man page for builtins(1) (on tuxworld).
3. In this question, you will be exploring the use of gdb for debugging programs by, for example, utilizing breakpoints and printing out the values of variables. You will be working with the supplementary C source file called power.c, a makefile used to build this program, and an example input file called infile.txt. power.c reads in a list of space-separated pairs of numbers, one pair per line. If you look at the source code for power.c, you will notice that the program reads either from a file (if a file is specified as a command-line argument) or from the standard input (if not). Therefore, power can be run either using "./power infile.txt" or "./power < infile.txt". For each line of input, the program outputs the value of the first number to the power of the second number, and-on the next line-the value of the second number to the power of the first number. The program assumes that the numbers in the input file are always non-negative integers. Files power.c, infile.txt, and makefile are in the tar(1) saveset Lab10Q3Files.tar.
Download the supplementary file for the lab, Lab10Q3Files.tar, unpack the tar saveset, and then perform the following steps.
(a) Run make to build the power executable. Then run power using infile.txt as the command-line argument. You should get a segmentation fault, a problem that can be very difficult to debug. You are going to use gdb to make the bug easier to find.
Note that because of your actions in question 2, you should have a core file created in your current working directory. Use the file command on the core file to show that it was created.
(b) Modify makefile so that debugging information is added to the executable when the program is compiled and linked. You don't need to hand in a log of your editing session-just 2hand in your modified makefile. Then rebuild the program using your modified makefile and giving the -W option to make. Note that you need to supply an argument to the -W option.
The changes to makefile in this step should be minimal-no more than are necessary to fulfil the specification above.
(c) Start gdb, specifying the program you want to debug (i.e. power). Then begin execution of power by issuing the "run" command (to gdb) with infile.txt as the argument. When the program stops after the segmentation fault, execute the gdb command "backtrace full". Examine the output carefully; there is a wealth of information made available.
(d) Continuing from step 3c, make a note of the line number (in the source code) at which the segmentation fault occurred. Using the gdb "list" command, output the source code surrounding this line of the program. Then using the gdb "frame" command, set the frame to frame 0. Now use gdb's "print" command to output the values of the memory locations pointed to by *a and *b. Perform any other gdb commands that might provide you with useful information for identifying the source of the "segfault" error.
When you feel you have gathered sufficient information, issue the "quit" command to gdb. You will probably get a message saying "A debugging session is active." and then asking you if you want to "Quit anyway". Answer to the affirmative.
(e) Based on the output from parts 3c and 3d, modify the swap function (and only the swap function) in power.c to fix the error. You do not need to hand in the log of your editing session.
Then rebuild the power program using make. Finally, run the power program again outside gdb. Your program should no longer "segfault", but the output will not be correct.
The changes to power.c in this step should be minimal - no more than are necessary to fulfil the specification above. Think about whether variable tmp should be of type int* or just int. If you add code to allocate dynamic memory, you are making excessive modifications.
(f) Start gdb, again specifying that you want to debug power. Set a breakpoint at the calc_pow function. Then run the power program (within gdb) with infile.txt as the argument.
When execution gets to the breakpoint, instruct gdb to display the contents of the variables num and pow each time the program stops. Repeatedly continue execution to the next breakpoint, noting the values of num and pow. An occasional backtrace will also be useful. Once you have identified the bug, exit gdb.
(g) Modify power.c so that calc_pow works correctly (note that one other "bug" is that 00 = 1, but we will ignore this). You do not need to hand in the log of your editing session. Run power outside of gdb to verify that the program now works correctly.
The changes to power.c in this step should be minimal - no more than are necessary to fulfil the specification above.
(h) Now that you've used gdb to debug this program, you will explore gdb a bit more. Start gdb with argument power, then list lines 18 through 24 of the (power) program. Set a breakpoint on one of the two lines that calculate the value of variable result (it does not matter which one).
Then run your program within gdb, but this time with standard input redirected to come from infile.txt (i.e. use input redirection as you would within a UNIX/LINUX shell).
(i) Gdb will know about the various C/C++ structured datatypes being used in your program, even the ones defined in system .h ?les. One such datatype is FILE as defined in stdio.h. Note that variable in_stream in power.c is of type FILE *. Continuing from step 3h, when the power program stops, output the value of the in_stream variable and the size (in bytes) of the in_stream variable. Then, with a single command, output the data type of the struct pointed to by (the value in) the in_stream variable. The output from the single command should include the data types of all the elements within the struct. If there is more than one screen full of output, display it all.
(j) Continue using gdb to examine the execution of power. Explore the functionality of gdb. Finally quit gdb.
Remember to submit your modified power.c and makefile. You can also remove any core files and reset your resource limit, if you wish.
Attachment:- Assignment Files.rar