USC CSD Home
 

Homeworks - CSCI 102L, Fall 2011

Each homework assignment is meant to be completed individually by students on their own time. Students will typically be given 2 weeks (give or take) to complete an assignment. Assignments are all submitted digitally via the USC Blackboard System. Submission instructions for each assignment can be found on the individual assignment pages.
 
Homework Assignments
(Please note that access to homework assignments is restricted.)
 
Homework Assignment Grading
All of the homework assignments will require students to prepare a design document. You can find a template for your design documents here.

There is a deduction penalty for a late submission. You can find the late policy here.

IMPORTANT: All assignments will be graded on the aludra/nunki UNIX systems. Before you submit your code, MAKE SURE that your code compiles and runs properly on aludra/nunki because that's where it will be tested and graded. An excuse such as "It runs just fine on my computer!" will not be accepted. Please also note that you must submit your code using the USC Blackboard System since the Blackboard System timestamps you submission.

 
Academic Integrity Policy
Please make sure you read the Academic Integrity Policy of this course.
 
General Information about Programming Assignments
(Please note that access to programming assignment related information is restricted. To receive user ID and password to access restricted information, please request access.)

The programming assignments will be C++ code to be developed on a UNIX environment. No other programming language will be accepted and your program must compile and run with a Makefile as is on a aludra/nunki.usc.edu. You must be familiar with the UNIX development environment (vi/pico/emacs, cc/gcc or g++/cxx, make, etc.)

You should use your USC accounts and preferably work on the Solaris machines in the ISD computer rooms for testing. The final (submitted) program must run on aludra/nunki because we are going to test it in that environment. But you should not do the whole program development there, as aludra/nunki is a general purpose server - under heavy use from many students. We will only grade from a grading account on aludra/nunki, so you must make sure your program runs correctly from any account on aludra/nunki. We cannot run your program from your account for the purpose of grading.

If a student signs up late for this class, he/she is still required to turn in all the assignments on time or he/she will receive a score of zero for these assignments. No exceptions! This requirement also applys to students on the wait list.

You must follow the Electronic Submission Guidelines when you submit programming assignments. You should also verify what you have submitted is what you intended to submit by following the Verify Your Submission procedure. Please note that it is your responsibility to ensure that you have submitted valid submissions.

 
Late Policy
Please see the late policy in the course description web page.
 
Modifications after Deadline
Please see the modifications policy in the course description web page.
 
Segmentation Faults and Bus Errors
I often get questions regarding segmentation faults and bus errors. Sometimes, these occue when one calls library functions such as gethostbyname(). Some students think this is some kind of a networking bug. Well, it's often not. I will try to answer this type of questions here once and for all.

Chances are that you have corrupted memory. This usually means that you have corrupted memory a while back. It just happened that when you call gethostbyname(), the corrupted memory caused a bus error or the execution of an illegal instruction. Bus errors and illegal instructions are basically the same thing as segmentation faults.

How does one corrupt memory? You can write beyond an allocated memory block. You can free the same object twice. You can free an object that was not allocated. You can write to an object that's already freed. These bugs are hard to find because most of the them you only see that there is problem long time after you have corrupted memory. If you have access to a professional/expensive debugging tool, it may be helpful. Otherwise, you just need to do binary search and see where the bug(s) might be. There's no magical cures in debugging memory corruption bugs.

One thing you might try is to temporarily turn off memory deallocation (if you suspect that you have freed the same object twice or freed an object that was not allocated). You can do the following to define free() as a no-op in a common header file when you are debugging:

    #define DEBUGGING_MEMORY_CORRUPTION
    /* comment out the above line when you are done debugging */
    #ifdef DEBUGGING_MEMORY_CORRUPTION
    #ifdef free
    #undef free
    #endif /* free */
    #define free
    #endif /* DEBUGGING_MEMORY_CORRUPTION */

As your code gets more and more complicated, and you are not very careful in managing your resources, you may get more of these. This is one reason why you want to keep your code nice and clean.

On aludra/nunki, you can try efence. There is a copy installed in:

    ~csci551b/public/efence/2.2/ElectricFence-2.2.2-15
Please read:
    ~csci551b/public/efence/2.2/README-solaris
I have not tried this library and I do not know if it's suitable for our programming assignments. But I've heard good things and bad things about it. Please try it at your own risk.

If you develop your code on a Linux, you can try valgrind. I have not tried this tool and I do not know if it's suitable for our programming assignments. But I've heard good things (e.g., easy to use) and bad things about it (e.g., it only runs on Linux). Please try it at your own risk.

Also, if you want to try these, incorporate them in your programs as early as possible. Don't start learning it when bugs are happening and deadlines are approaching.

 

[Last updated Mon Sep 17 2012]    [Please see copyright regarding copying.]