Frequently Asked Questions
Last updated
Last updated
This page is a, continuously growing, database of commonly asked questions/issues and possible answers/solutions. There is no specific order to the entries. If you have an issue yourself, make sure you search this page (⌘F | Ctrl + F) for some keywords that may be associated with your issue. If you do not find a solution here, you may ask a TA during your Lab session or use the Canvas Discussion board.
One of the great things about using a UNIX-based operating system is that it (very likely) includes manual pages for most (if not all) functions of the C Standard Library.
If, for instance, you want to know how the fopen function works and what arguments you need to pass it, you can simply type
man fopenin a Terminal window. This will open the manual page (or short man page) for the fopen function. This page should give information about the parameters, functioning, and return value of the function. To close the page simply press 'q'.
You are probably passing uninitialized memory to the printf function. For example, you may be loading a value from an address on the stack before having initialized this value with a prior mov instruction.
Trace the value(s) of the register(s) that printf will use for printing to localize the issue. It may help to use a debugger to follow the register values (and their changes) throughout the program.
printf?One possible cause of this issue may be the stack alignment. As explained on the page about , the stack needs to be 16-byte aligned for any subroutine calls. For some subroutines a misaligned stack may not be an issue, however, functions of the C Standard Library will likely exit with a segmentation fault.
When using the shortcut targets (like make a1) make is checking for the exit code of your program (so the return value of the main routine). You are likely not returning 0 from your main routine and thereby, as non-zero return codes are typically used to indicate unsuccessful termination, make assumes that something went wrong.
For reasons that we are not yet certain of, any labels starting with an l (so for example loop_1:) cause the debugger to no longer associate the lines in the source file with the instructions of the assembled program. The workaround for this is to name your labels such that they do not start with an l.
If a test on CodeGrade fails, but your local implementation runs without error, it might be the case that you are not using address sanitization in your own tests.
In the highly unlikely case that a test fails due to an internal error, please contact the teaching team as soon as possible.