Getting Help with Homework 4

Ask your Homework 4 questions here. Use the box at the bottom of this page. Your question is posted to this page for the class to see, under an animal name rather than your own—and if you would rather only the course staff saw it, there is a box to tick for that.

Course staff read this page. So do your classmates, and a classmate answering first is a good outcome rather than a failure of the system.

Before you ask

• Run valgrind and read the first error. On this assignment most bugs are memory bugs, and the first thing valgrind complains about is usually the real cause; later errors are often fallout.
• make clean then make. If valgrind reports no line numbers, or your change seems to have no effect, a stale build is the usual reason.
• Check the help pages — Using Valgrind, the CS 70 Testing Library, and Working With Makefiles.
• If your question is about a lesson rather than the assignment, ask on that lesson's Key Points page instead, where it sits next to the material.

Asking a question we can actually answer

• Push your code first. Commit, push, and say so — then whoever picks up your question can look at the real thing rather than at a description of it.
• The exact command you ran—pasted, not summarised.
• The exact output or error, in full, in a ``` code block. Compiler, linker, and valgrind output is long and the useful line is often not the last one, so paste all of it.
• What you expected instead, and what you have already tried.

Things that go wrong on Homework 4 specifically

• Memory leaks / invalid delete. Remember delete[] (not delete) for array allocations, and that every new[] needs exactly one matching delete[]. Say what valgrind reported and which method it points at. (If what it reports comes from ncurses, see Valgrind and the maze display below.)
• Circular-buffer bugs in CoordVector. If offset_ doesn't wrap correctly in both directions, say what you pushed/popped and what came out.
• A solver finds the goal but not the path. BFS must reconstruct the actual path, not just confirm reachability.
• Makefile trouble. Paste your Makefile and the exact make output.
• Your partner's copy works and yours doesn't. Usually one of you has not pulled the other's latest commits. Pull first, then say what still differs.

Valgrind and the maze display

When the maze display is on, valgrind's report includes memory that the ncurses library (which draws the maze) keeps on purpose: a few blocks "possibly lost" in functions like _nc_tiparm, newterm or vidputs, about 120 KB "still reachable", and an ERROR SUMMARY that counts them. That isn't your code, and the autograder doesn't use the display, so it never sees it.

To check your own code without that noise, either

• run without the display, as in valgrind --leak-check=full ./amaze -n mazes/maze-21x7.txt, or
• keep the display and tell valgrind to ignore what ncurses keeps. Save the lines below as ncurses.supp in your home directory (not in your repository, where the autograder would count it as an extra file):

# Valgrind suppressions for memory the ncurses library keeps on purpose.
#
# ncurses holds on to its screen and terminfo data after endwin(), and
# caches the results of its own tparm() calls, so a program that uses it
# shows "possibly lost" and "still reachable" blocks that aren't the
# program's doing.  These entries hide ONLY blocks that ncurses itself
# allocated; anything your own code allocates still shows up.
#
# Use:  valgrind --leak-check=full --suppressions=ncurses.supp ./amaze ...
{
   ncurses-tparm-cache
   Memcheck:Leak
   match-leak-kinds: possible,reachable
   ...
   fun:_nc_tiparm
}
{
   ncurses-library
   Memcheck:Leak
   match-leak-kinds: possible,reachable
   ...
   obj:*/libncurses*.so*
}
{
   terminfo-library
   Memcheck:Leak
   match-leak-kinds: possible,reachable
   ...
   obj:*/libtinfo.so*
}

and then run

valgrind --leak-check=full --suppressions=$HOME/ncurses.supp ./amaze mazes/maze-21x7.txt

With the suppressions, anything valgrind still reports, "still reachable" included, comes from your code; add --show-leak-kinds=all to see where it was allocated. (For example, forgetting to delete the Display in disableDisplay() shows up as "still reachable", because a Display keeps a pointer to itself.)

When a conversation would be faster

• Ask in lab, especially for anything where someone looking at your screen beats a paragraph of description.
• Come to grutoring or office hours for anything conceptual, or for the questions that are hard to phrase.
• For anything personal, or about the course rather than the code, contact a professor directly.

(When logged in, completion status appears here.)