One interview question. about debugging [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I have been asked this question today.

When debugging, there is an error. But after you add one printf() line. No error. What are errors can cause this.

This is an open question. So just let me say what I thought.

My answer was not logical 开发者_运维问答at that time. (such as, maybe some memory error? maybe have concurrency issue?) So what to hear sth you may have.

Some people may say this is not a good or not a reasonable question. But when we dealing with interview, we have no choice. We need to say what ever logical and make it make sende. :)

---

The concurrency issue is pretty valid. An I/O operation such as printf takes really long compared to other operations, and this sometimes hides a race condition (the problem doesn't go away, it just manifests less often - harder to debug).

Imagine somebody comes up with this flawed idea:

• Start a thread
• Initialize some memory location that will be read by that thread

At this point there's no telling what will happen. If the thread starts really quick, it will read the memory location before the starting thread has a chance to write it. If however the new thread simply prints "Oh hay, I'm a new thread" before reading the variable, it has a pretty good chance to read valid results. Of course, in 1/10 cases it will fail and it will be a pain to debug.

---

The trigger-word he was looking for was "heisenbug" - a bug that disappears when trying to study it.

I would list three common errors that may cause this in order of likeliness:

1. The printf-statements has sideeffects. In the simplest case something like printf("%d", i++);. In this case the code always works wihtout the statement and never when its there.
2. As already mentioned - Race conditions between threads where the printf introduces a slight delay reducing the likelihood that the bug will appear. The bug may however still appear even without the statement.
3. Memory corruption - The stack or heap was corrupted by bad pointer code at a previous point. The call to printf reveals this and crashes. Also in this case the program will likely crash later even without the statement.

---

Here are my guesses:

The printf() was modifying some variable; say an argument was ++i

printf() is an i/o operation, which takes a considerable time WRT the other non-i/o operations. Maybe it prevented some race condition.

printf() returns some value. Maybe the function had an int return type but no return statement, so in the assembly (at least this happens in gcc, x86-64) the last returned value is returned.