MP Grading Policy

CS 241, Spring 2012

ORGANIZATION OF FILES

This file is one of two instruction files associated with machine problems in CS 241. This file describes how to submit your MP, grading details, and other details that are shared between all MPs in CS 241. With each MP, there is a separate file that explains the specific details on the MP.

TESTING YOUR PROGRAM

In CS 241, your program will only be run by course staff on 64-bit EWS Linux Terminal Server. The address of the 64-bit EWS Linux Terminal Server is linux.ews.illinois.edu.

You may access these boxes via SSH using any program that understands the SSH protocol (ex: `ssh` on Mac/Linux, `putty` on Windows).

Since all testing and grading by course staff will be done on the terminal server machines, it is STRONGLY ADVISED that you test your program on a terminal server machine before submission. The fact that your program "runs perfectly" on a CSIL machine will get you zero points if your program does not run at all on an EWS terminal server machine.

GRADING YOUR PROGRAM

The grading of each MP will be broken up into three different categories.

• Standard Machine Problem Correctness (90%):
  For each MP, the course staff will run automated tests by our autograder on every file that has been submitted by the due date. This autograder will have a number of different tests, each assigned with a weight based on its importance, and your grade will be simply be the result of your total score by the autograder.
  
  As soon as your program is autograded, an autograder report will be placed inside your subversion directory for CS 241. This report will explain how your program was tested, what output your program gave, and if that output was correct or not.
  
  Due to the large size of this class, the only way to ensure fairness across all students is to use the same autograder for every student and for no exceptions to be made. If you believe that your program works completely correct, it may be an error in the autograder. For errors in the autograder, we will correct the autograder and re-run the autograder on every student's submission. However, if the error is in your code -- even if it's a minor error that results in a large point drop -- exceptions will not be made since we are unable to examine the errors of every single submission.
  
  Grades may change as the autograder is rerun with corrections. This may result in your MP report grade changing. Until grades are posted on Compass, they should not be considered final and may still go up or down based on your program's correctness.
  
  Finally, to recieve full credit, your MP must run in a resonable amount of time. After an excessive amount of time, the autograder will kill your process and award you points for only the tasks you've completed up to the point when the autograder killed your program. We will always set the time out to be at least ten times longer than the TA solution takes to run.
  
  
• Memory Management (5%):
  Unlike higher level programming languages such as Java and C#, there is no garbage collector in C. Instead, every single bit of memory that you allocate in a C program remains allocated to your program until your program frees that memory -- even if there doesn't exist a pointer to that memory because you've cleared it or because it has gone out of scope.
  
  We will use a common C dynamic analysis tool called `valgrind`. You can run valgrind on your own program by running the following line of code:

  valgrind myprog arg1 arg2 ...

  To receive full credit for this portion of the grading:
  1. Your program must be reported at "leak free" by valgrind by displaying the following text in its valgrind report:

     All heap blocks were freed -- no leaks are possible.

  2. Your program must perform tasks in a reasonable amount of memory. You may lose points if you complete a task by simply allocating a *large* amount of memory for a task that requires only a small amount of memory. For example, if you need to program a dictionary to store key/value pairs. Using an array[1000000] may work, but hardly manages memory well (or works for more than one million entries). You will need to use over ten times the optimal amount of memory before any points would be deducted for excessive use of memory.
  
  Finally, if your program does not complete significant parts of the MP, you may not be awarded points for memory management. For example, some MPs may require you to open/read/write a large number of files. If you never use open()/fopen() because you didn't complete that part of the MP, you will not receive memory points for correctly close()'ing your files.
  
  You will be awarded full credit or no credit. There is no partial credit for this 5%.
  
  
• Strictly Correct Memory Usage (5%):
  In the previous 5%, the grading looked at if you correctly free'd the memory you allocated in your program. In this 5%, the grading looks at if you didn't write into memory you didn't allocate.
  
  Using the same valgrind tool, you will receive full credit for this portion of the grading if and only if your valgrind report shows:

  ERROR SUMMARY: 0 errors from 0 contexts (suppressed: # from #)

  If the error summary does not report 0 errors, valgrind will have displayed other error information above the error summary giving you details of where the illegal access occurred. For example:

  Invalid write of size 2
    at 0x400519: main (in /home/cs/wfagen2/temp/mystring)
  Address 0x4C37039 is 9 bytes inside a block of size 10 alloc'd
    at 0x4A05809: malloc (vg_replace_malloc.c:149)
    by 0x4004A9: main (in /home/cs/wfagen2/temp/mystring)
  

  is generated by a strcat() past the end of a memory region.
  
  You will be awarded full credit or no credit. There is no partial credit for this 5%.
  
  

SUBMISSION