The attached application demonstrates that after few steps the debugger stops working and no further step events are generated by the back-end. Resume does not help, since after suspend the program remains in the same state.

Steps to reproduce:
- unzip the attached deadlockingApp.zip into an empty folder.
- execute ./run in some terminal window
- in an other terminal window, go the folder where deadlockingApp.zip was unzipped and follow the instructions in jdb.HOWTO

What is going on:
The debuggee starts up and run one more instance of itself, now with some arguments. This is in HandlerImpl.execSecondInstance(). After the second instance starts up, is creates a socket communication with the first one and passes some arguments to it. Then it ends. The first instance is being debugged right after this communication. After several steps it usually freezes. StepEvent does not come, several iterations of suspend/resume do nothing. If this does not happen the first time, repeat the whole process once more, it will certainly happen.

It might be important to mention that the freeze can not be reproduced without the second instance of the application. Therefore the code that performs the communication (combined with the debugger intervention) probably does something that cause the debuggee to stop responding.