`Processing lsp` never exits and leaves orphaned processes
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 72/100
Línea de trabajo
Empieza en java/src/processing/mode/java/lsp/PdeLanguageServer.java y revisa exit(), que solo imprime una línea, y main(), que descarta el future devuelto por launcher.startListening(). Comprueba qué ocurre cuando stdin llega a EOF y cómo debería terminar el proceso en ese caso. Está terminado cuando el proceso LSP finaliza al cerrarse VS Code o al fallar. Puedes confirmarlo con pgrep -af 'Processing lsp' después de cerrar el editor.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Most appropriate sub-area of Processing 4?
Other (specify if possible)
Processing version
processing-4.5.7-1435 (AUR processing-bin)
Operating system
Arch Linux x86_64
Bug description
The LSP server never terminates when the client goes away. This way, after closing Visual Studio Code with official Processing extension via File > Exit (or Ctrl+Q), the Processing LSP process is left running. The process also survives abrupt client death, since nothing on the server side reacts to the client disappearing.
Steps to reproduce this
- Install Processing 4.5.7 and the official Processing Visual Studio Code extension.
- Open Visual Studio Code
- Quit Visual Studio Code with Ctrl+Q (File > Exit).
- Run:
pgrep -af 'Processing lsp' - The process is still running.
snippet
No response
Additional context
PdeLanguageServer.exit() only prints a line and never calls System.exit(). PdeLanguageServer.main() also ignores the future returned by launcher.startListening(), so nothing happens when stdin reaches EOF. As a result, nothing in the server can end the LSP process when the client disappears.
Would you like to work on the issue?
Yes, I’d like to help with this
- Lenguaje dominante
- Java
- Estrellas
- 513
- Forks
- 183
- Merge medio
- 4 h 6 min
- PR fusionados (30 d)
- 4
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de processing/processing4
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
processing/processing4#1554 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
processing/processing4#1515 · 1 reacción ·
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
processing/processing4#1573 · 3 comentarios ·
-
startup errorAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
processing/processing4#1569 · 7 comentarios ·
-
Binaries under bin directory lack executable permissions for the snap and .deb packages for LinuxPosiblemente ocupada @catilac la tomó hace 24 días. Abiertobug
processing/processing4#1567 · 3 comentarios · 1 reacción · 1 asignado ·
Todos los issues de processing/processing4
Issues similares
-
Use GHA setup gradle actionPosiblemente ocupada @bric3 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
openhab/openhab-addons#21921 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
jellyfin/jellyfin-androidtv#5885 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
priority:P2 product:orazaka type:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día