Autograder Ouput and Error Messages
Your program or program components produced behavior that matched the correct solution on this test.
Your program (or its components) executed without crashing or hanging (indicated by other messages), but its behavior did not match the correct solution. Validate your code against the specifications. If your code matched the provided samples in your development environment, but failed the corresponding sample tests on the autograder, it almost certainly means that your code is relying on platform-specific undefined behavior. See the other troubleshooting suggestions.
Compile or link error messages
The autograder uses gcc/g++ and makefiles to build an executable of your whole program, and then additional executables for any component tests where your components are combined with our testing drivers or project components. If a build succeeds, you will get none of the compiler or linker messages. But if a build fails, your feedback email will contain all of the compiler and linker error messages and warnings for that build. Some of the warnings might differ from your own version of gcc, and are often not important, but any error messages are critical. Study them to determine the problem.
make: *** No rule to make target X ...
This is a message from the make utility that the autograder uses to build executables. Usually this is caused by failing to submit one of the required files that is needed to compile the component named X. Check to make sure you have supplied all the specified files (and to be safe, only the specified files).
Unfortunately, changes in the autograder machine OS have made this result ambiguous. The possible causes are: (1) The value provided to the system on program termination was not zero. If you return from main, or exit() with a non-zero value, this can result. Be sure your program always returns 0 from main except where the specifications tell you to use exit(). (2) There was a memory allocation/deallocation error. (3) A maximum time or file limit was exceeded. See TIMED OUT and FILE LIMIT.
The program attempted to access an invalid virtual memory address. Both this and BUS ERROR are usually due to "wild pointers" - e.g. uninitialized pointers, garbage addresses, dereferencing null pointers. etc.
The Unix SIGBUS error, in the context of this class, almost certainly indicates that your program attempted to access data with an invalid address alignment, or more generally, an impossible memory address. Both this and the SEG. FAULT error are usually due to "wild pointers" - e.g. uninitialized pointers, garbage addresses, dereferencing null pointers. etc.
The Unix SIGABRT condition arose, which indicates that abort(), or terminate() was called. An uncaught exception would cause terminate() to be called. If an assert() "fires", this will also cause SIGABRT.
You exceeded a predefined runtime limit. In some project tests, this would happen if your code was grossly inefficient for the amount of data involved (like using a O(n^2) algorithm). More often, it is due to your program hanging in a loop of some sort. If your program fails to respond correctly to all input commands and fails to handle incorrect commands properly, it can get out of step with our testing script and never see the quit command that terminates the script - and just loops forever, doing something like spitting out the unrecognized command error message.
You exceeded a predefined limit for data output to stdout. Infinite loops that generate output sometimes cause this message rather than TIMED OUT. See TIMED OUT.