Race condition at the end of hot code replacement causes inconsistent UI state
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
Research direction
Start with JavaHotCodeReplaceProvider.redefineClasses() and stepIntoThread(ThreadReference), then inspect ProtocolServer.sendEvent(DebugEvent) and its handling of StoppedEvent and ContinuedEvent. Reproduce or trace the StepEvent timing, and consider the issue done when the VS Code UI consistently reflects the target process as suspended after hot code replacement.
Written by the indexing model from the issue text.
Description
At the end of JavaHotCodeReplaceProvider.redefineClasses() execution JavaHotCodeReplaceProvider.stepIntoThread(ThreadReference) is called which sends JDI StepRequest to the target process and subscribes for StepEvent, on reception of which the following events for the UI are populated in that order:
context.getProtocolServer().sendEvent(new Events.StoppedEvent("step", thread.uniqueID()));
context.getProtocolServer().sendEvent(new Events.ContinuedEvent(thread.uniqueID()));
However, ProtocolServer.sendEvent(DebugEvent) usually reverses this order by putting StoppedEvent to the event queue until ProtocolServer command processing (redefineClasses in this case) has completed. All other types of events are sent immediately. As JDI StepRequest is usually processed very quickly by the target process, the usual order for the VS Code UI to receive the events is ContinuedEvent > StoppedEvent. In contrast, if StepRequest processing happens to be slow then StoppedEvent is sent first and ContinuedEvent as the final one. In that case the Debug toolbar in VS Code UI will be shown like in running state with Stop button while the target process is still suspended.
- Dominant language
- Java
- Stars
- 409
- Forks
- 204
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 4
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/java-debug
-
ai-triaged bug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
microsoft/java-debug#611 · 2 comments ·
-
ai-triaged enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
microsoft/java-debug#608 · 3 comments ·
-
ai-triaged question
Difficulty 5/5 Over a week Newbie friendliness 30/100
microsoft/java-debug#597 · 1 comment ·
-
ai-triaged bug
Difficulty 4/5 3-5 days Newbie friendliness 25/100
microsoft/java-debug#588 · 1 comment ·
-
ai-triaged question
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
microsoft/java-debug#582 · 1 comment ·
All issues in microsoft/java-debug
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
FasterXML/jackson-databind#6229 ·