|
Homeworks - |
| All homework assignments must be done individually. (Although you are encouraged to discuss homework assignments with other students, when it comes time to code, you must not look at any shared code and write all your code on your own.) |
| Homework Assignments |
(Please note that access to homework assignments is restricted.)
|
| Grading Guidelines |
|
[BC: Section added 3/18/2007] We will make grading guidelines available at least one week before an assignment is due. We will grade based on the grading guidelines (may be with minor adjustments). Since you know exactly how we are going to grade, the grading will be harsh. Also, you do not get credit for coding. You only get credit for getting your code to work correctly according to the spec. (Please do not ask the grader to look at your code so you can get more points because you have done a lot of coding and your code looks like it should work.) |
| Modifications after Deadline |
|
For programming assignments,
you are allowed to make modifications, submitted via
e-mail to the instructor,
within 24 hours of the submission deadline.
One line (128 characters max) of change is defined as one of the following:
Afterwards, additional modifications cost 12 points per line (until 7 days past the original submission deadline). Please note that this applies to source code, Makefile, and README files. |
| 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 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.
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.
|