Eclipse & other Java IDEs for debugging concurrent code.

Question

I'm currently working on some concurrent code that would appear to have a few race conditions in it. I'm attempting to debug the code using my current IDE, Eclipse, but I'm not completely satisfied. In particular, a race condition is present for a variable such that without a break point on one of the methods accessing it (the one 'getting' it), the variable setting method does not complete, and the variable is set to null. However, if I put a break point on the accessing method, and hold F8--the default step over button--the variable is almost always set to the correct (non-null) value.

This leads me to ask the following: is it possible that Eclipse doesn't pause execution on the breakpoint across all threads quickly enough that I can look at the potential race condition as it appears without a break point, or is something else (probably) happening?

If it is the case that Eclipse doesn't pause execution quickly, are there other IDEs/debuggers for Java that may do a better job of this? Note that I'm not looking for formal verification tools like Java Pathfinder--I don't want to check if race conditions are present, I want to see them unfold in my debugger (if only because it might be interesting to watch).

Answer 1

This leads me to ask the following: is it possible that Eclipse doesn't pause execution on the breakpoint across all threads quickly enough that I can look at the potential race condition as it appears without a break point, or is something else (probably) happening?

Well, not only this, but the very presence of the debugger alters the environment in such a way that you are not reproducing the identical situations you get when running your program for real. Eclipse will pause some threads when they hit your breakpoint, but other threads that don't hit the breakpoint can keep running and continue to alter your data.

Troubleshooting race conditions with a debugger is pretty hard - not only are you looking for a needle in a haystack but the debugger alters the structure of the haystack.

You are possibly much better off being able to reason about the code and the strategies you take for handling concurrent code. For example, are you protected shared state with locks? How/what are you synchronizing on? To be able to write to variable foo, what steps do threads have to go through?

Answer 2

Remember that accessing/setting variable is not guaranteed to be done in one step. You probably want to use atomic object to be sure.

And also remember that the variable value may be cached. To make sure it is not cached, use volatile.

And if you forgot, you can set the breakpoint for variable. Just click the left side of the variable declaration like when you create a normal breakpoint.