Debugging a program that crashes 10 times in different places [closed]

Question

You are given the source to an application which is crashing during run time. After running it 10 times in a debugger, you find it never crashes in the same place. The application is single threaded, and uses only the C standard library. What programming errors could be causing this crash? How would you test each one?

Answer 1

Your code could be invoking anything with undefined behaviour in the C standard, including (but not limited to):

1. Not initialising a variable but attempting to use its value.
2. Dereferencing a null pointer.
3. Reading or writing past the end of an array.
4. Defining a preprocessor macro that starts with an underscore and either a capital letter or another underscore.

The list is long, but Annex J.2 in the C specification provides a concise list of undefined behaviour.

Answer 2

• disk full, i.e. other processes may delete a different file causing more space to be available
• code depends on timer
• memory issue, i.e. other processes allocate and/or free memory
• a pointer points to a random location in memory that is changed by another process causing some values be "valid" (very rare though)

In general a situation with other process is likely. Note that you said that only your program is single-threaded, others may run in parallel.

Answer 3

Easy: infinite loop. Only crashes when the call stack overflows, and that could happen anywhere, depending on how much memory is available for the call stack.

Answer 4

If you assume there is a single error and the application crashes in different places, it might be a dangling pointer. Accessing an already freed piece of memory will give you rubbish values (probably a segfault in most cases), they will be seemingly randomly overwritten as the application creates and destroys variables and does memory operations. This could be as easy as a missing malloc or a free too much.

However, I wouldn't bother to debug the app at all if first attempts don't reveal the source of the problem. If an application crashes in ten different places, when the app uses seemingly unrelated data, the author surely has written tons and tons of code without ever compiling and testing it in the process and now is helpless because one error led to another. I would politely ask the app's programmer to have an intercourse with himself, and after he's done, to rewrite the faulty code from scratch, compiling and testing every few lines.

Answer 5

The answer they're looking for is use of an uninitialized variable, and depending on it being it's default value. E.g:

int a; // default value 0
int b[10];

int main() {
  for (;a++;a<10) {
    b[a] = 0;
  }
}

This will not crash when debugging, because you debug unoptimized code, so the default value will be applied. Nothing goes wrong with a starting out as 0. Gcc -O3 or -Os, however will not initialize the value, making it a random value, very unlikely to be 0, and b[a] will increase in address (in the "average case", caveats apply) until outside of the data segment, leading to SIGSEGV.

There will be a compiler warning about this though.

You can make this question harder by relying on link attributes. (look up what "static int c" does in the global scope).