Week 8 - Wednesday CS222

Last time What did we talk about last time? Memory Random number practice

Questions?

Project 4

Quotes Good design adds value faster than it adds cost. Thomas C. Gale

Software Engineering Starting with some motivation…

Therac-25 Radiation treatment machine for cancer patients Caused: Used June 1985 - Jan 1987 Caused: At least six serious overdoses Several deaths Many permanently maimed Radiation treatment is normally around 200 rads 500 rads can be lethal Therac-25 delivered dosages of over 20,000 rads because of a software error 11 units in US and Canada had treated hundreds of patients over the course of several years Earlier Therac-20 and Therac-6 models had been in service, without incident, for many years

Problems not caught for two years The doctors involved had never seen radiation overdoses of this magnitude Manufacturer was both tragically ill-prepared and probably willfully dishonest Government regulatory agencies slow and out of the loop The fundamental problem stemmed from the machine having two different modes Low power which projected a beam directly into the patient High power which projected a beam onto a beam spreader plate which changed the kind of radiation and shaped it

Race condition One of the problems behind the Therac-25 disaster was a race condition What is a race condition? You should have seen one in CS122 A race condition is when the output of a program is dependent on the scheduling of certain threads Consider the following, where variable counter starts at 0 and is shared between both threads What is the value of counter after both threads have executed? //thread 1 int i = 0; for(i = 0; i < 500; i++) counter++; //thread 2 int j = 0; for(j = 0; j < 500; j++) counter++;

Race conditions in Therac-25 The problem emerged with the Therac-25 only after operators became skilled at typing commands It took time for the keyboard loop to read keystrokes and time for the magnets to adjust the radiation beam Operators changed settings faster than the 8-second magnet alignment loop The device could activate in high power mode with no beam spreader plate

Overflow error Even with the race condition, a safety check should have prevented the accident There was a loop which checked a counter The value 0 meant okay The counter was only 1 byte Every 256 cycles, it would roll around to 0 When that happened, the operator could proceed without a safety check

Subsequent investigation The Therac-25 software was programmed by a single programmer, who had long since left the company No one at the company could say anything about his education or qualifications FDA investigators said Program was poorly documented No specification document No formal test plan

In the programmer's defense Therac-6 and 20 had no computer control, only add-on computer monitoring Legacy software from the earlier devices had been adapted Hardware safety devices had been removed, probably to save cost Programmer had probably been under time pressure, and had been learning as he went along Programmer probably had no idea his code would go into a device in which software bugs could kill people

Who is to blame? Techniques for synchronization and data sharing already existed which would have prevented several of these deaths What if the programmer had a formal education that involved these techniques or had bothered to study the literature? What if management had understood software engineering and quality assurance principles? What if hospitals or regulatory agencies had strong safety requirements for safety-critical software?

Quotes A significant amount of software for life-critical systems comes from small firms, especially in the medical device industry; firms that fit the profile of those resistant to or uninformed of the principles of either system safety or software engineering. Frank Houston FDA investigator into the Therac-25

Will you write important software in your lifetime? Odds are, some of you will write software for medical devices, cars, planes, spacecraft, major financial institutions, and so on You have the opportunity here and now to choose the course of your software writing life Will you comment your code only when you think it's necessary? Will you write test cases only after you're done, and only if you have time? Will you have the discipline and courage to write the safe, correct, robust, and reusable software of the future?

Testing

Unit testing Unit tests are tests for a single piece of code in isolation for the rest of your program A unit test could test A single method or function A whole class Give some good unit tests for: Project 1 Project 2 Project 3

Test case selection Positive test cases Boundary condition test cases Cases that should work, and we can easily check the answer Boundary condition test cases Special cases, like deleting the first or last item in a list Sometimes called "corner cases" Negative test cases Cases that we know should fail

Test suites You should made a series of tests for every significant program you write Include positive, boundary, and negative tests Create the necessary files for input and output Use your favorite scripting language to automate the process of testing so that you can easily run all the tests every time you change something

Regression testing When you find a bug, keep the test case that demonstrated the bug Include it as part of your test suite Always run all your tests when you make a change to your code Sometimes a "fix" can break something that was working Especially if you didn't fix the bug correctly the first time

Black box testing One philosophy of testing is making black box tests A black box test takes some input A and knows that the output is supposed to be B It assumes nothing about the internals of the program To write black box tests, you come up with a set of input you think covers lots of cases and you run it and see if it works In the real world, black box testing can easily be done by a team that did not work on the original development

White box testing White box testing is the opposite of black box testing Sometimes white box testing is called "clear box testing" In white box testing, you can use your knowledge of how the code works to generate tests Are there lots of if statements? Write tests that go through all possible branches There are white box testing tools that can help you generate tests to exercise all branches Which is better, white box or black box testing?

Traces There are some great debugging tools out there, even for C We'll talk about GDB in a bit Microsoft Visual Studio has very nice debugging tools for C/C++ in Windows But you (almost) always have printf() (or some other output function) Don't be shy about using printf() to see what's going on in your program It is convenient to use #define to make a special print command that can be turned off when you are no longer debugging

Finally… Understand each error before you fix it If you don't understand a bug, you might be able to "fix" it so that one test case succeeds Nevertheless, the real problem might be unsolved Nothing is harder than truly fixing problems This is the skill we want to teach you more than any other

Quotes Testing can only show the presence of bugs, not their absence. Edsger Dijkstra Turing Award Winner Designer of shortest path and MST algorithms Worked on Dining Philosophers Problem Hates the goto construct

Debugging

printf() debugging A time-honored technique for debugging is inserting print statements into the code int i = 0; int count = 0; for( i = 1 ; i <= 100; ++i ); // mistake { printf("%d\n", i); // see what's up count += i; } printf("%d\n", count);

Problems with printf() Using print statements is a good, general technique However Be sure not to actually change the state of the program with an i++ or other assignment inside the printf() It may not be available in some GUI programs or in deep systems programming It might mess up the output of your program Remember to remove your debug statements before turning in your code

Another approach It turns out that there are two kinds of output to the terminal stdout (where everything has gone so far) stderr (which also goes to the screen, but can be redirected to a different place) The easiest way to use stderr is with fprintf(), which can specify where to print stuff fprintf(stderr, "Going to stderr\n!"); printf("Going to stdout\n!");

Redirecting streams When you redirect stdout, stderr still goes to the screen This will be incredibly useful for debugging Project 4 If you want to redirect stderr to a file, you can do that as well with 2> ./program > out.file This stderr output still shows up. ./program > out.file 2> error.log

Newline Whether using stderr or stdout, it's critical that you use a newline (\n) to flush your output Otherwise, the program crash might happen before your output is seen printf() uses a buffer, but the newline guarantees that the output will be put on screen int* pointer = NULL; printf("Made it here!"); // Not printed *pointer = 42; // Crash!

GDB

GDB GDB (the GNU Debugger) is a debugger available on Linux and Unix systems It is a command line utility, but it still has almost all the power that the Eclipse debugger does: Setting breakpoints Stepping through lines of code Examining the values of variables at run time It supports C, C++, Objective-C, Java, and other languages

Prerequisites C doesn't run in a virtual machine To use GDB, you have to compile your program in a way that adds special debugging information to the executable To do so, add the -ggdb flag to your compilation Note: You will not need to do this on Friday's lab gcc –ggdb program.c –o program

Source code GDB can step through lines of source code, but it cannot magically reconstruct the source from the file If you want to step through lines of code, you need to have the source code file in the same directory as the executable where you're running GDB

Starting GDB The easiest way to run GDB is to have it start up a program Assuming your executable is called program, you might do it like this: It is also possible to attach GDB to a program that is running already, but you have to know its PID You can also run GDB on a program that has died, using the core file (which is why they exist) gdb program

Basic GDB commands Command Shortcut Description run r Start the program running list 135 l List the code near line 135 list function List the code near the start of function() print variable p Print the value of an expression backtrace bt List a stack trace break 29 b Set a breakpoint on line 29 break function Set a breakpoint at the start of function() continue c Start running again after stopping at a breakpoint next n Execute next line of code, skipping over a function step s Execute next line of code, stepping into a function quit q Quit using GDB

GDB tips Set breakpoints before running the code The print command is absurdly powerful You can type print x = 10, and it will set the value of x to 10 This kind of manipulation will be key to solving the next lab For more information, use the help command in GDB You can also list your breakpoints by typing info breakpoints

Some String Issues

A few final string issues What if you have a number and want a string version of it? In Java: What if you have a string that gives a numerical representation and you want the number it represents? int x = 3047; String value = "" + x; //quick way value = Integer.toString(x); //fussy way String value = "3047"; int x = Integer.parseInt(value);

String to integer In C, the standard way to convert a string to an int is the atoi() function #include <stdlib.h> to use it #include <stdlib.h> #include <stdio.h> int main() { char* value = "3047"; int x = atoi(value); printf("%d\n", x); return 0; }

Implementing atoi() Now it's our turn to implement atoi() Signature: int atoi(char* number);

Integer to string Oddly enough, this is a stranger situation Many systems have a non-standard function (also in stdlib.h) called itoa() It takes the int, a buffer to hold the resulting string, and the base The portable way to do this is to use sprintf() It's like printf() except that it prints things to a string buffer instead of the screen char value[10]; //has to be big enough int x = 3047; itoa( x, value, 10 ); char value[10]; //has to be big enough int x = 3047; sprintf( value, "%d", x );

Implementing itoa() Now it's our turn to implement itoa() We'll restrict ourselves to a base 10 version Signature: It returns the pointer to the string in case this call is nested inside of another call (to strcat() or printf() or whatever) char* itoa(int number, char* string);

Users and Groups

Users Recall that each user on a Linux system has a unique login name and a unique numerical identifier (the UID) Users can belong to one or more groups as well Where is this information stored?

Password file The system has a password file stored in /etc/passwd Each line of this file corresponds to one user in the system and has seven fields separated by colons: Login name Encrypted password UID GID (group ID of the first group that the user is a member of) Comment Home directory (where you are when you log in) Login shell (which shell you running when you log in) Example: wittmanb:x:1000:100:Barry Wittman:/home/wittmanb:/bin/bash

Catch-22 Your computer needs to be able read the password file to check passwords But, even root shouldn’t be able to read everyone’s passwords Hash functions to the rescue!

Cryptographic hash functions Take a long message and turn it into a short digest Different from hash functions used for hash tables Lots of interesting properties (lots more than these): A small change in the message should make a big change in the digest Avalanching Given a digest, should be hard to find a message that would produce it Preimage Resistance Should be hard to find two messages that hash to the same digest (collision) Collision Resistance

The Linux and Unix solution Instead of storing actual passwords, Linux machines store the hash of the passwords When someone logs on, the operating system hashes the password and compares it to the stored version No one gets to see your original password Not even root!

Back to the password file Inside the password file, we have encrypted passwords Everyone's password is safe after all Login Name Password Hash ahmad IfW{6Soo baili 853aE90f carmen D390&063 deepak CWc^Q3Ge erica e[6s_N*X1

Shadow password file Even though the password is disguised, it is unwise to let it be visible to everyone Given a password digest (the hashed version) and lots of time, it is possible to figure out the password It's useful for the password file to be readable by everyone so that all users on a machine are known to all others A shadow password file stores the encrypted password and is readable only by privileged users /etc/shadow

Changing your password Amid all this discussion, it might be useful to know how to change your password I don't recommend that you do change your password I'm honestly not sure how doing so will interact with your Active Directory (Windows) password The command is passwd Changing password for wittmanb. (current) UNIX password: Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully

Changing the owner of a file You recall that we can change permissions for who can read, write, and execute a file using chmod But chmod depends on who the owner is What if you want someone else to be the owner of a file? The chown command can let you do that If I want my file stuff.txt to be owned by Dr. Leap, I would use the following command On most systems, chown only works if you are root chown leap stuff.txt

Groups Files are associated with a group as well as a user who is owner The groups are listed in the /etc/group file Each line of this file corresponds to a group and has four fields separated by colons: Group name Encrypted password Often not used Group ID (GID) User list Comma separated Example: users:x:100: jambit:x:106:claus,felli,frank,harti,markus,martin,mtk,paul

Creating a group If you want to create a group, you have to be root If you're root (or using sudo), you can use the groupadd command To create the awesome group as root: Or using sudo: groupadd awesome sudo groupadd awesome

Adding a user to a group Again, you have to be root to add a user to a group Use the useradd command To add user wittmanb to the awesome group as root: Or using sudo: useradd –g awesome wittmanb sudo useradd –g awesome wittmanb

Changing the group for a file When you create a file, it is associated with some default group that you belong to You can use the chgrp command to change to another group that you belong to If you are root, you can use the chown command to change the group, using a colon chgrp awesome file.txt chown :awesome file.txt

Upcoming

Next time… Time from the Linux perspective Lab 8

Reminders Keep working on Project 4 Read LPI Chapter 10