- fix the back-end event handler's handling of the completion of a pop to notice that
when the thread is resumed, an invoke is to be done instead of a normal resume
- fix the back-end to remember the state of invoke being allowed or not when a
popFrames operation is begun, and restore that state when the popFrames finishes.
See attached webrev.
When the back-end reports an event to the front-end, the thread on which the event
occurred is suspended. If an invokeMethod command is received, the back-end
sets some special flags and resumes the suspended thread. The suspended
thread resumes inside the event-handler which checks those special flags to see if an invoke is to be done, and if so, the event handler does the invoke instead of letting the thread resume its normal processing.
When JVM Ti completes a pop operation, an internal step event is received by the back-end event handler. The event handler notices that this is a special event and does some processing to complete the pop operation. When the thread is resumed in this state, it doesn't check the special flags to see if an invoke is to be done, but just resumes normal processing. To prevent this from happening, the back-end
generates an error which results in the IncompatibleThreadStateException being thrown if an invokeMethod is attempted while the thread is in this state.