-
Notifications
You must be signed in to change notification settings - Fork 0
/
Common_Errors.txt
21 lines (12 loc) · 2.16 KB
/
Common_Errors.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Section 1: Mac vs. Linux
----------------------------------------------------------------------------------------------
You are welcome to use a macbook for your development. However, please make sure to have a Linux VM so that you can test your code on a Linux machine. This is to save our time and yours, as TAs will not always be available to run your code on our test server.
A) Mac includes libraries by default that Linux doesn't. Please make sure that functions which are called on your machine have the necessary libraries included for running on Linux.
See https://www.kernel.org/doc/man-pages/ to see what libraries need to be included and linked for each function call.
B) Please define necessary feature test macros. As an example, the default client file includes _XOPEN_SOURCE. The linux manual pages, posted above, will tell you what needs to be defined to call various functions. Note that not all features are compatible with each other.
C) Install gdb. A guide on how to do so can be found here, https://www.ics.uci.edu/~pattis/common/handouts/macmingweclipse/allexperimental/mac-gdb-install.html, although the steps may differ from machine to machine.
Section 2: Other common mistakes
----------------------------------------------------------------------------------------------
A) Please close all file descriptors. Certain operating systems (both Linux based and Mac OS X) will cover for you if you do not close file descriptors when you are done writing data, however data is not guaranteed to be flushed to disk if a file descriptor is not closed correctly. This leads to non-deterministic behavior, missing data, and varying behavior across machines, making debugging hard.
B) Be careful to send and recieve exactly the same number of bytes. Often times off by one errors can accumulate and lead to programs crashing at weird times or both sides of a socket waiting for the other (which is observed as a "hang"). This behavior is also very hard to debug.
C) Memory errors can be validated using Valgrind. As a helpful hint, whenever segfaults are occurring or you aren't sure why errors are happening, try using Valgrind to see if you are touching unallocated memory.