|
Project Assignments - |
|||||||||||||||
| Projects | |||||||||||||||
|
(Please note that access to project related information is
restricted. You should have received a password in your e-mail.)
The class project will be C/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 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 nunki.usc.edu because we are going to test it in that environment. But you should not do there the whole program development, as nunki is a general purpose server - under heavy use from many students. Late submissions will receive severe penalties. Due to clock skews, electronic submissions of projects and homeworks assignments will be accepted within 15 minutes after the specified deadlines without penalties. If your submission is beyond the 15 minutes grace period, you will receive 75% of your grade if your submission is 15 minutes late beyond the grace period; you will receive 50% of your grade if your submission is 30 minutes late beyond the grace period; you will receive 25% of your grade if your submission is 45 minutes late beyond the grace period; and you will receive a score of zero otherwise. All submissions will be timestamped by the submission server and receipts will be issued. Whether your submission arrived to the server by the deadline is determined by the timestamp. Please keep your receipts. If a student signs up late for this class, he/she is still required to turn in the warm-up projects 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. The first 2 project assignments are considered warm-ups. The final project assignment is divided in 2 parts. You must follow the Electronic Submission Guidelines when you submit project assignments. Please note that this is a brand new procedure and very different from previous procedures. Grading and deadlines:
|
|||||||||||||||
| Modifications after Deadline | |||||||||||||||
|
You are allowed up to 3 lines of changes, submitted via
e-mail to the grader, the TA and the instructor, within 24 hours
of the submission deadline.
One line (128 characters max) of change is defined as one of the following:
For 3 points per line of modification, you can submit additional modifications after the modification deadline mentioned above. (Up to 3 modifications submitted before the modification deadline were free of charge.) The definition of a line remains the same. Both parts (1) and (2) of the final project are worth a total of 100 points each. These additional modifications has a deadline of 1 days from the modification deadline. |
|||||||||||||||
| 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. 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 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 projects. But I've heard good things
and bad things about it. Please try it at your own risk.
Also, if you want to try this, incorporate it in your programs
as early as possible. Don't start learning it when bugs
are happening and deadlines are approaching.
|
|||||||||||||||