# Debugging a submission that works well on student's computer but not on my computer

I teach a course in C++. Often, students submit a homework assignment that works well in their computer (they send me a screenshot showing that it compiles and runs perfectly), but when I run the assignment on my computer, I get a "segmentation fault". This is, most probably, due to some pointer-related bug or an uninitialized variable, that results in an "undefined behavior": in the students' computer this "undefined behavior" happens to work fine, but it is still an error.

When I tell this to the students, they do not know how to work towards solving the problem, since they cannot even see it on their computer. There are 160 students (with 2 instructors and 3 TAs) in the course, and I do not have time to debug their submissions on my computer, or to give them my computer for debugging.

One solution is to have a shared server, and have all students submit their exercises in the same server, so that everyone - including me - work in exactly the same environment. However, currently I do not have such a server so students work on their own computers, which can be Windows, Linux or Mac.

Additionally, having an identical environment for everyone is not a complete solution, since it is still possible that a submission happens to work well on this identical environment, despite it having an "undefined behaviour" bug. An identical environment thus only guarantees that, if the students do not see an error, then I will not see it too.

How can I help students debug their code in this situation?

EDIT: A related problem is that, when the students submit such a solution and I tell them they have a bug, they say "the bug is in your computer! See, my code works well on my computer!". So a related question is: how can I explain to them that there is a bug in their code, even when they do not see it?

• Then debug the fault on your computer and tell them where the fault is... (I have 200 students on my course and I DO this, as there are so few that need debugging to this extent.) – Brian Tompsett - 汤莱恩 Feb 23 '20 at 22:10
• I guess I'm not understanding something basic. These are not final submissions, but code to edit? What are the understandings between you and your students about sending code back to refactor? – Ben I. Feb 23 '20 at 22:46
• Do you have a lot of TAs? What is the student to staff ratio for a course like this. It is easy to predict chaos if it is too high. I'll note that Harvard's CS50 has a lot of students but the ratio between students and staff is about 20/1. And some of the staff have specialized duties. – Buffy Feb 24 '20 at 0:28
• @BrianTompsett-汤莱恩 I believe my job as an instructor is to teach my students how to debug their code, and not debug their code for them... just like when they work in the industry, they should not expect their clients to debug their code. – Erel Segal-Halevi Feb 24 '20 at 13:48
• @ErelSegal-Halevi I guess I'm still not understanding. As a somewhat rhetorical question, why not just deduct from their grade and call it a day? Are the students expecting feedback? Do they get to resubmit their code without penalty? – Ben I. Feb 24 '20 at 15:10

You've said that having an identical environment for everyone would be an incomplete solution, since students' code could still work "by accident" in that environment. One option would be to provide access to two or more sufficiently different environments which would be the same for everyone; such environments could be provided in several ways, for example:

• Distribute virtual machine images, with instructions for how students can use them to test their code.
• Provide access to virtual machines through a paid service; for example, Codio is specifically designed for use in CS education.
• There are some web services such as repl.it, which compile and run your code, and show the results in a console.
• Some universities have student-run computing societies offering accounts for students on a shared server.
• Different environments may already be available if students are on campus, and the campus has enough different computer labs open for student use at some times.

To catch undefined behaviour when grading submissions, you could test their code in the same two (or more) environments that students have been encouraged to use. Assuming you have a script that can automatically run all submissions, it shouldn't be a lot of extra work to run that script twice.

Another option is to provide students with a software tool which can detect and report undefined behaviour, as discussed in this Q&A on Stack Overflow. Such a tool could also be used to give feedback to students whose submissions fail on your machine during grading; although static analysis and other techniques won't generally be able to detect all kinds of undefined behaviour, the kinds they do detect should cover most or all of the mistakes that students are likely to make.

• Very interesting tools. I have to try them out. – Erel Segal-Halevi Feb 25 '20 at 6:28

Your student/staff ratio is pretty unfavorable. This makes everything difficult. If you had a few more TAs or could find the schedule time, I'd make one of the TAs the person to handle all such technical issues. It would need to be the one with the highest "geek cred" I think. But debugging stuff shouldn't be the instructor's job.

Part of the job of the super geek TA would be to figure out why such things happen and to feed it back to the instructors so that such things can be avoided in the future.

The symptoms you exhibit might be as simple as the fact that student machines probably have different memory configurations and so bounds errors might get caught on one, but not another. And if they have different OS's and different versions of C++ then there are lots of places for failure.

But with over a hundred students, your time isn't well spent debugging the code of individuals. Appeal to the administration for adequate support. Offload such things to that support staff.

Your top geek might also be able to schedule a periodic "debugging lab" for students.

You could encourage them to use tools like compiler warnings and valgrind to try to check for bugs.

As early as possible in the course, and again when appropriate examples arise, you should "round up the usual suspects." (It's a Dick Tracy reference, but that does not really help.) You could include this as a "sidebar" feature of many classes. And you could have a "crib sheet" listing the most common such mistakes.

For example one frequent mistake is the "wild pointer." You allocate memory using "new" and have a pointer point at it. Then you later delete this memory through the pointer. Then still later you reference the same memory through the pointer. Your program no longer owns that memory, it's a protection fault. There are several common variations on this, and it can be very hard to debug.

This is just one example. There are a bunch of these. If you make them aware of these early in the class then hopefully you will get them learning how to code well, not just vigorously. In C++ there are a number of idioms that seriously reduce wild pointers.

You could dedicate part of one class to debugging an example of this kind of error. It would probably save you a lot of time marking assignments. Or if they have tutorial time, that could be a task you drop on your tutors.

You could get them into the following books to look for more, and other related issues. These are the books I wish I had when I was learning C++.

https://www.amazon.com/Exceptional-Engineering-Programming-Problems-Solutions/dp/0201615622/

https://www.amazon.com/Accelerated-C-Practical-Programming-Example/dp/020170353X/

https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/

Is this using different versions of gcc? Have the students compile with full warnings and with different level of optimizations.

I wonder: could the emitted warnings be of a kind that the compiler will only warn about at a certain optimization level?

Either way: making the students see the effects of this type of side-effect is very valuable in itself. Now, how to ensure that they deduce the issues, that would be interesting and valuable.