3

I am facing this eclipse error while debugging:

org.eclipse.jdi.TimeOutException: Timeout occurred while waiting for packet 220 occurred creating step request.

I googled a bit and also checked it on stackoverflow but have not found any solution. I am working on Mac OSx and using Eclipse Kepler but I get the same error on Windows 7 with Eclipse Mars. I am using Java 1.8.0_25, 64-Bit Server VM (build 25.25-b02, mixed mode)

Lanc
  • 880
  • 12
  • 25
  • Please provide at least eclipse version and VM version you run eclipse in and VM version of the target you are debugging. A stack trace would also be good. – Gerd Castan Dec 25 '15 at 19:31
  • I updated the question. Eclipse just freezes and there is no crash. So I don't have any stack trace. – Lanc Dec 25 '15 at 19:45

2 Answers2

4

I was also facing the same eclipse error while trying to debug the multi-threaded program code. Reducing the number of break points allowed me to debug the code without any errors. I believe there is some limit to place the debug/watch points in eclipse (w.r.t stack memory).

Increasing the Java stack size could be other solution. Info can be found here.

Community
  • 1
  • 1
Bhanu Gowda
  • 41
  • 7
2

It seems this problem has been mentioned on the Google Code forums:

The problem seems to occur because the tick [producer] thread doesn't play well with the debugger.

It's suggesting that problems occur with the debugger when you have 2 threads (a producer and a consumer thread), and you attempt to suspend the consumer thread.

The workaround:

If you put a breakpoint to pause the tick thread, then you can step through both test threads nicely.

This suggests that you should set a breakpoint within the producer thread (not the consumer thread). Apprently the timeout occured when putting a breakpoint on the consumer thread, and putting a breakpoint on both threads caused an IllegalStateException.

I hope this helps!

The idea is to block the producer thread, which forces the consumer thread to wait (assuming it's blocked while waiting for data, not polling). You can then resume the producer thread, which resumes the consumer thread for that "tick". The producer thread goes back to waiting.

Apparently, it takes 2 of these cycles to represent 1 "tick", as suggested by the person who found the workaround:

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.

Vince
  • 14,470
  • 7
  • 39
  • 84
  • Thanks! But I didn't fully get it, so you are saying that I put the breakpoint in producer thread and all the way step to the consumer thread, right? But I want to debug the code in consumer thread, how do I do it? I tried doing what you suggested started from producer thread and step through the consumer but still getting same error. – Lanc Dec 25 '15 at 21:10
  • @Lanc I have updated my answer :) If you are still having problems, I will attempt to reproduce the issue once I'm home tomorrow (out of town for Christmas). Is it possible to update your Java? The latest version is 8u66, which comes with some concurrency patches. Not sure if it's relevant to your issue at the moment - I'll confirm once I am home – Vince Dec 25 '15 at 21:42
  • Thanks @Vince I updated my Java to 8u66 but doesn't help much. I still did not understand how to block the producer thread for a tick. Ok see u later...Merry Christmas!! – Lanc Dec 25 '15 at 23:35