11

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?

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
guerda
  • 23,388
  • 27
  • 97
  • 146
  • How can you have both a language-agnostic and java tag, thats a bit of an oxymoron – UnkwnTech Jul 10 '09 at 07:52
  • I considered [java] because I thought I need to tell more about my program and be java specific. It's not necessary, so I removed the tag. – guerda Jul 10 '09 at 07:55
  • The language is of some relevance in this question. I'd save language-agnostic for design questions, requirements, etc. – Daniel Daranas Jul 10 '09 at 07:57
  • 2
    Totally off-topic, but thanks for showing off the tag, didn't know SO supported it. Nice! – unwind Jul 14 '09 at 08:40

7 Answers7

11

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.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • 1
    If the problem is truly caused by race conditions, logging style debugging will only make the situation more confusing. If the problem isn't, your way is probably the best. – pmr Jul 10 '09 at 12:30
  • `java.io.PrintStream.println(String)` invokes synchronization, which causes delays among other things (e.g., a race on the very resource you're debugging?). So even a poor man's debugger is likely to have unintended side-effects. See: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/io/PrintStream.java#PrintStream.println%28java.lang.String%29 – Dan Barowy May 05 '15 at 15:39
6

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.

pmr
  • 58,701
  • 10
  • 113
  • 156
3

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.

guerda
  • 23,388
  • 27
  • 97
  • 146
  • Why are you answering to yourself as if you were two different people? – Daniel Daranas Jul 10 '09 at 07:58
  • 1
    How could I answer it on another way? As I imagine stackoverflow, it may be helpful for other users, too. – guerda Jul 10 '09 at 08:03
  • No, I don't. I'm searching for tips that may help in such a situation. And all of these answers could (!) help. – guerda Jul 10 '09 at 08:08
  • 1
    I think your own tips should instead be listed in the question. Not added as an answer – l3dx Jul 10 '09 at 08:18
  • 1
    These are very basic strategies, that should be listed in your answer, such as "I've already tried...". Otherwise this looks a bit like a contest. – Daniel Daranas Jul 10 '09 at 08:24
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

Manuel Selva
  • 18,554
  • 22
  • 89
  • 134
0

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!

George Phillips
  • 4,564
  • 27
  • 25
0

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.

DerMike
  • 15,594
  • 13
  • 50
  • 63
0

I was running into something similar.

My problem: Set.iterator was producing different results in debug and in run.

Of course, my code had a bug that indirectly counted on the order of the set elements.

MFARID
  • 700
  • 1
  • 12
  • 18