What to do, if debug behaviour differs from normal execution?

Question

I have a problem with debugging sessions. My program executes very well in a debug session but if I start a normal run, it behaves completely different.
The problem is, that I cannot say, why it acts different.

One possible reason is the slower execution time because you alway have to press F6 or so.
I tried to insert Thread.sleep(1000); but I don't get the instruction causing the different behaviour.

So: What are hints, best practices to get to know why it acts so different in debug sessions?

Answer 1

You might observe a race-condition that only occurs when there are no debug statements that slow down execution. It could be helpful to start with reviewing your threading model and to watch out for any possible locks.

Answer 2

It's really difficult to debug multi threaded applications.

You can try to debug using the old System.out.println technic instead of using the debugger ... may be this will allow you to debug while having the different behavior you mentioned.

Manu

Answer 3

Two solutions:

a) Use poor man's debugger (print to the console) or use a logging framework. After the error happens, analyze the output.

b) Write a test case that tries to reproduce the problem. Even if you can't find it that way, this will clean your code and sometimes solve the issue.

Answer 4

I tried to check my assumption I did and check them once more.

Excessive logging could be helpful in some situations, but not always. In my case, it didn't help that much.
With logging you can see, where your assumptions are correct and which of them fail.

My personal solution was Java specific. The Java ClassLoader does not load classes completely since JDK 1.5. In a debug session, it has to be loaded completely. So some variables were not initialized well and the output differed from the normal run.
That reason is very hard to find.

Answer 5

Check some easy stuff first. Does the crashing version get the same command line arguments? Or special environment variables? Or user ID? Or some other factor you know to be important. In other words, are you really running it with the same input, as it were. Does it crash all the time? Does it crash in the same place? If you can hook up a debugger after the crash where it broke may provide some clues. Is some recent change a possible culprit? If so, try removing it and see what happens.

Don't get too hung up on these attempts. They're just guesses which are great if they pay off quickly but ultimately unproductive as there are millions of possible differences between "running under a debug" and "running wild and free".

Otherwise, cut the differential analysis and work the problem. That is, look directly at what goes wrong in the crash instead of itererating over possible causes.

Here are a couple of book exceprts that may help you "debug without the debugger".

Chapter 5, "Debugging" from "The Practice of Programming"

The 9 rules from "The 9 Indispensable Rules for Finding the Most Elusive Software and Hardware Problems

Good luck!

Answer 6

A bug like this, that goes away when you use the debugger, is sometimes called a Heisenbug.

Answer 7

NB: Not necessary multithreading related.

For me it helped sometimes to set different breakpoints.

Sometimes evaluating the values changes them (e.g. reading iterator values).
Secondly your "false" breakpoints may inhibit parallelism and race conditions.