Replicating a bug on client's machine

Question

I'm currently studying C at university. I've been tasked to write a C program which gives the correct output on my PC and the University's PC's but not on the professor's PC. The professor has provided me with the output of my program on his PC and he has tasked me to find the bug.

I looked at the logic and the expected output and there is no correlation between them. Surely it is not a logic error if it is running on 2 out of 3 computer.

When I asked the professor to mark the assignment based on the school's computer, he disagree and ranted on about the real world that if it doesn't work on just one computer, my program is buggy.

So I want to ask real world professionals out there what they would do in this situation? How can you debug a program if the program is not buggy on the tool provided to you for testing purposes? That is, if a customer report a bug which you cannot replicate yourself, what can you do? Or how do you go about replicating the bug?

FYI, my computer is windows, the school's computer is linux, and the professor's computer is a Mac.

Answer 1

I looked at the logic and the expected output and there is no correlation between them. Surely it is not a logic error if it is running on 2 out of 3 computer.

Welcome to Undefined Behavior: unfortunately, the fact that your program produces correct results on two (or on two thousand, for that matter) computers proves nothing. The language standard tried to give compiler designers as much freedom to optimize as possible, so that the efficiency of C++ programs could stay competitive with programs written in assembly language. Unfortunately, this leaves a lot of room for incompatibility between platforms: different compilers and execution environments can generate drastically different results for programs with bugs. The worst thing is, programs with bugs may produce behavior that you may reasonably expect on some platforms, and crash miserably on others!

The only way to guard against undefined behavior is to write correct programs. Compilers reasonably aid you by producing warnings in places where they think an undefined behavior may be happening. Turn on all warnings at the finest level, compile your program, and fix all warnings the compiler reports. Chances are, some of the warnings would explain the differences between the output on your computer and on the computer of your professor.

For tracking down advanced errors, use valgrind. This program will help you detect memory-related issues, such as writing past the allocated area, using released memory, freeing the same chunk of memory multiple times, and so on.

Answer 2

1) Defensive programming. Do not assume that things will work. Do you need to open a file? Check that it exists. Do you load a data structure? Check the data structure was correct.

1a) Meaningful user errors: If the file is not there, show the user a "Could not find file 'file.txt' in path C:\items". Do not just keep going ahead.

2) As posted in a comment, log everything. More for a school project (where performance is not critical), log everything into a file and check what is the path your program is doing, and (when possible), why (what are the data structure values).

2a) Given the close relationship, you can define a test case for the professor to run in its computer. Check his log against yours.