6

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?

moinudin
  • 134,091
  • 45
  • 190
  • 216
hiddenboy
  • 981
  • 7
  • 6
  • 12
    Are you currently being interviewed? – Eimantas Dec 25 '10 at 21:29
  • There is no right answer to this question - it really depends on the platform which errors could be possible from a description like this. – Johan Kotlinski Dec 25 '10 at 22:27
  • @Eimantas: no, just saw this question online. – hiddenboy Dec 27 '10 at 19:22
  • The code-paths taken depend on input data as well. If input data OR for that matter any external data to the program varies, then there is reasonable explanation of it erring at different places. errors like corrupted structure may cascade due to this, only to be found at various different points in program. – Munish Goyal Jan 06 '11 at 19:08
  • 1
    @hiddenboy hyperlink? –  Apr 16 '13 at 21:55
  • Question 11.2(answer 12.2) in Cracking the Coding Interview. – Jared Burrows Mar 22 '15 at 21:59
  • I will enter a similar interview for Google internship in a short time. I have been told that interview may take around 45 minutes and I may have to write a program on paper. I felt shy to ask the recruiter during our online meeting, but I wonder if I can use internet or other resources such as some paper notes to remember things during such a technical interview. Is there anyone who has an idea ? – Ferda-Ozdemir-Sonmez Dec 12 '16 at 09:10

5 Answers5

15

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.

dreamlax
  • 93,976
  • 29
  • 161
  • 209
  • ref: http://stackoverflow.com/questions/367633/what-are-all-the-common-undefined-behaviour-that-a-c-programmer-should-know-abo – J.J. Dec 25 '10 at 22:01
  • yes.. but the interesting point in this question is: it will not crash when debugging. – hiddenboy Dec 27 '10 at 19:23
  • 1
    @hiddenboy: That makes no difference. Undefined behaviour is undefined, which means a program may act differently every time it is executed and also may act differently depending on how it is executed. The only thing you know for certain is that it is not guaranteed to work. – dreamlax Dec 27 '10 at 23:37
  • While (4) is UB, I highly doubt it would actually cause that kind of crashing. – Billy ONeal Jan 03 '11 at 02:54
9
  • 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.

sjngm
  • 12,423
  • 14
  • 84
  • 114
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.

Joel
  • 31
  • 1
  • I should qualify what I mean by infinite loop is that function A is calling function B, and function B is in turn calling function A. Sort of like recursion. – Joel Oct 07 '11 at 16:07
  • Here's an interesting problem: If you have a circular reference as described above (A() calls B() and B() calls C(), ... until Z() calls A()), and, as the above problem states, you run it 10 times, and every time, it crashes at a different function in the loop, how many functions do you need in the loop to ensure with 95% certainty that it will crash at a different place each of the 10 times you run it? – Joel Oct 07 '11 at 16:32
  • 1
    The problem you need to solve is: N!/((N-10)! * N^10) = .95 The solution I get is N = 880. – Joel Oct 07 '11 at 16:33
2

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.

mingos
  • 23,778
  • 12
  • 70
  • 107
1

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).

oelewapperke
  • 41
  • 3
  • 1
    The variable `a` will *always* be initialised with 0, because it is at file scope (i.e. it has static storage). The rules are different if a variable does not have static storage, but because this variable does, it will *always* be initialised to 0. – dreamlax Apr 24 '12 at 07:32
  • Did you even try compiling it with those flags? The behaviour shouldn't change. Also, because `b` also has static storage, all the elements are also initialised to 0. `-O3` may be smart enough to realise that the whole program does nothing. – dreamlax Apr 24 '12 at 07:34