zeng233 / multithreadedtc

Automatically exported from https://code.google.com/archive/p/multithreadedtc/
0 stars 0 forks source link

Eclipse debugger times out #3

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
When I try to step through a test thread method using the eclipse debugger,
I get this error message:
org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet
6783. occurred creating step request.

I set up a simple class that writes and reads to a LinkedBlockingQueue.
Then I created a test for it with one thread reading an item, and the other
thread waiting for tick 1 before writing an item.

I put a break point on the first statement of the reader thread, but as
soon as I try to step into the method, it gives me the Timeout exception.

If I put a break point on both threads, then the test fails with this message:
java.lang.IllegalStateException: No progress
    at edu.umd.cs.mtc.TestFramework$1.run(TestFramework.java:445)

That makes sense, I guess, but how can I step through the two threads in
the debugger?

Original issue reported on code.google.com by donkir...@gmail.com on 26 Sep 2008 at 8:35

GoogleCodeExporter commented 8 years ago
I found a workaround. The problem seems to occur because the tick thread 
doesn't play
well with the debugger. If you put a breakpoint to pause the tick thread, then 
you
can step through both test threads nicely.

The best location I found for a breakpoint was the call to Thread.Sleep() in
TestFramework.startClock() line 359.

When they're both blocked waiting for a tick, you can release the tick thread 
until
one of the test threads is released, and then leave the tick thread blocked 
again
until you need the next tick. It seems to take two cycles of the tick thread to
advance one tick.

In the eclipse debugger window, the relevant thread states are: 
* Suspended - it's paused in the debugger and ready to be stepped forward.
* Stepping - it's currently executing something, but is being blocked. When 
released,
it will go back to the suspended state.
* Running - never been paused. Running on its own.

Original comment by donkir...@gmail.com on 26 Sep 2008 at 8:48

GoogleCodeExporter commented 8 years ago
The same issue (and workaround) apply to the debugger in Netbeans.

Original comment by daniel.r...@gmail.com on 29 Jan 2010 at 3:53