Race condition at the end of hot code replacement causes inconsistent UI state
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 38/100
Direção de pesquisa
Comece com JavaHotCodeReplaceProvider.redefineClasses() e stepIntoThread(ThreadReference), depois inspecione ProtocolServer.sendEvent(DebugEvent) e o tratamento de StoppedEvent e ContinuedEvent. Reproduza ou rastreie o momento de StepEvent e considere a issue concluída quando a VS Code UI refletir consistentemente que o processo de destino está suspenso após a substituição de código a quente.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Java
- Estrelas
- 409
- Forks
- 204
- Merge médio
- 1d 13h
- PRs com merge (30d)
- 4
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de microsoft/java-debug
-
ai-triaged bug
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
microsoft/java-debug#611 · 2 comentários ·
-
ai-triaged enhancement
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
microsoft/java-debug#608 · 3 comentários ·
-
ai-triaged question
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 30/100
microsoft/java-debug#597 · 1 comentário ·
-
ai-triaged bug
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 25/100
microsoft/java-debug#588 · 1 comentário ·
-
Is Hamcrest a dependency? Abertaai-triaged question
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 35/100
microsoft/java-debug#582 · 1 comentário ·
Todas as issues de microsoft/java-debug
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 75/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
FasterXML/jackson-databind#6229 ·