<p>Is this using different versions of <code>gcc</code>?
Have the students compile with full warnings and with different level of optimizations.</p>

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

<p>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, <em>that</em> would be interesting and valuable.</p>

CC BY-SA 4.0
2020-03-04T14:02:13.317Z
2020-03-04T22:39:05.660Z
2020-03-04T22:39:05.660Z
Stefan Skoglund
<p>You could encourage them to use tools like compiler warnings and <code>valgrind</code> to try to check for bugs.</p>

CC BY-SA 4.0
2020-02-24T21:31:59.523Z
2020-02-24T21:31:59.523Z
Solomon Ucko
<p>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 <em>two</em> or more sufficiently different environments which would be the same for everyone; such environments could be provided in several ways, for example:</p>

<ul>
<li>Distribute virtual machine images, with instructions for how students can use them to test their code.</li>
<li>Provide access to virtual machines through a paid service; for example, <a href="https://www.codio.com/" rel="nofollow noreferrer">Codio</a> is specifically designed for use in CS education.</li>
<li>There are some web services such as <a href="https://repl.it/languages/cpp" rel="nofollow noreferrer">repl.it</a>, which compile and run your code, and show the results in a console.</li>
<li>Some universities have student-run computing societies offering accounts for students on a shared server.</li>
<li>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.</li>
</ul>

<p>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.</p>

<hr>

<p>Another option is to provide students with a software tool which can detect and report undefined behaviour, as discussed in <a href="https://stackoverflow.com/q/7237963/12299000">this Q&amp;A on Stack Overflow</a>. 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 <em>all</em> kinds of undefined behaviour, the kinds they do detect should cover most or all of the mistakes that students are likely to make.</p>

CC BY-SA 4.0
2020-02-25T06:28:46.717Z
Very interesting tools. I have to try them out.
Erel Segal-Halevi
CC BY-SA 4.0
2020-02-24T17:10:39.690Z
2020-02-24T22:12:17.503Z
2020-02-24T22:12:17.503Z
kaya3
<p>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.</p>

<p>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.</p>

<p>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.</p>

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

<p>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++.</p>

<p><a href="https://rads.stackoverflow.com/amzn/click/com/0201615622" rel="nofollow noreferrer" rel="nofollow noreferrer">https://www.amazon.com/Exceptional-Engineering-Programming-Problems-Solutions/dp/0201615622/</a></p>

<p><a href="https://rads.stackoverflow.com/amzn/click/com/020170353X" rel="nofollow noreferrer" rel="nofollow noreferrer">https://www.amazon.com/Accelerated-C-Practical-Programming-Example/dp/020170353X/</a></p>

<p><a href="https://rads.stackoverflow.com/amzn/click/com/0735619670" rel="nofollow noreferrer" rel="nofollow noreferrer">https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/</a></p>

CC BY-SA 4.0
2020-02-25T21:09:18.613Z
2020-02-25T21:09:18.613Z
puppetsock
<p>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. </p>

<p>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. </p>

<p>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. </p>

<p>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. </p>

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

CC BY-SA 4.0
2020-02-24T14:01:38.900Z
2020-02-24T14:31:12.200Z
2020-02-24T14:31:12.200Z
Buffy
<p>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. </p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>How can I help students debug their code in this situation?</p>

<p>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?</p>

CC BY-SA 4.0
2020-02-23T22:10:48.580Z
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 - 汤莱恩
CC BY-SA 4.0
2020-02-23T22:46:39.363Z
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.
CC BY-SA 4.0
2020-02-24T00:28:37.013Z
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
CC BY-SA 4.0
2020-02-24T13:48:30.083Z
@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
CC BY-SA 4.0
2020-02-24T13:51:14.100Z
@BenI. these issues can happen both before and after the submission deadline. The situation is similar: the students think that their code is fine and do not see any problem with it.
Erel Segal-Halevi
CC BY-SA 4.0
2020-02-24T13:52:28.067Z
My question, above, is a serious one. Depending on the answer, I might have some advice. How many TAs?
Buffy
CC BY-SA 4.0
2020-02-24T13:53:36.960Z
@Buffy there are 2 instructors, 3 TAs, and 160 students.
Erel Segal-Halevi
CC BY-SA 4.0
2020-02-24T15:10:56.237Z
@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.
CC BY-SA 4.0
2020-02-25T06:25:28.060Z
@BenI. Sure I can deduct from their grade, but then they complain that it is unjustified because their submission works well, it is only my computer that is wrong..
Erel Segal-Halevi
CC BY-SA 4.0
2020-03-04T12:08:51.220Z
@ErelSegal-Halevi: I deal with this. Their complaints are unwarranted. You should be able to point to a specific uninitialized variable in the code, say it causes undefined behavior, end of story. If they can't pick up on that prohibition then it's not your problem.
Daniel R. Collins
<programming><c++><homework><debugging>
Debugging a submission that works well on student's computer but not on my computer
# Debugging a submission that works well on student's computer but not on my computer

(Asked by: username_0 on 2020-02-23)

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?

**Tags:** programming, c++, homework, debugging

> **Comments:**
> **username_1**: 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.)  
> **username_2**: 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?  
> **username_3**: 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.  
> **username_0**: @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.  
> **username_0**: @BenI. these issues can happen both before and after the submission deadline. The situation is similar: the students think that their code is fine and do not see any problem with it.  
> **username_3**: My question, above, is a serious one. Depending on the answer, I might have some advice. How many TAs?  
> **username_0**: @username_3 there are 2 instructors, 3 TAs, and 160 students.  
> **username_2**: @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?  
> **username_0**: @BenI. Sure I can deduct from their grade, but then they complain that it is unjustified because their submission works well, it is only my computer that is wrong..  
> **username_4**: @ErelSegal-Halevi: I deal with this. Their complaints are unwarranted. You should be able to point to a specific uninitialized variable in the code, say it causes undefined behavior, end of story. If they can't pick up on that prohibition then it's not your problem.  

---

## 5 answers

### Answer by username_7 on 2020-02-24. Score: 5

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](https://www.codio.com/) is specifically designed for use in CS education.
* There are some web services such as [repl.it](https://repl.it/languages/cpp), 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](https://stackoverflow.com/q/7237963/12299000). 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.

> **Comments:**
> **username_0**: Very interesting tools. I have to try them out.  

---

### Answer by username_8 on 2020-02-25. Score: 3

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://rads.stackoverflow.com/amzn/click/com/0201615622)

[https://www.amazon.com/Accelerated-C-Practical-Programming-Example/dp/020170353X/](https://rads.stackoverflow.com/amzn/click/com/020170353X)

[https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/](https://rads.stackoverflow.com/amzn/click/com/0735619670)


---

### Answer by username_3 on 2020-02-24. Score: 3

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.


---

### Answer by username_5 on 2020-03-04. Score: 2

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.


---

### Answer by username_6 on 2020-02-24. Score: 2

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


---

