Electron JS app.quit() hang on Linux and Mac
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- csharp, electron, javascript
- Área
- desktop
Línea de trabajo
Reproduce el bloqueo con el módulo más sencillo de la carpeta examples del repositorio y la demo vinculada daniacedue/electron-nodeapi. Empieza por la ruta de app.quit() de Electron y la limpieza del módulo AOT de .NET/C#, comparando el comportamiento en macOS y Linux. Se considera terminado cuando la aplicación se cierra correctamente después de cargar el módulo, permitiendo que electron-updater inicie una actualización sin terminar el proceso a la fuerza.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hello,
If I use this technology in an Electron JS desktop application to load a C# AOT or .Net module then on Mac OS (and also Linux) the call to app.quit() hangs and the app does not closes normally, needing to do a force quit from Activity Monitor.
It happens with the simplest possible module found in your examples folder, as it is too much code I have made a demo app here:
[daniacedue/electron-nodeapi] (https://github.com/daniacedue/electron-nodeapi)
As a workaround I have tried brutally closing the process after some time or in the Electron's app.quit() handler by doing process.kill(process.pid, "SIGKILL"); but this is problematic because I need electron-updater npm package to be able to gracefully close in order to kick-off an update.
The problem is quite complex, I have also tried asking some chatbots to figure out what is happening by interpreting some stack traces and spindumps and it has something to do with low-level NAPI calls freezing the main process when doing the cleanup.
I have tried numerous "black box" possible fixes from both C# and JS (like explicit "destroy" function triggering dispose pattern because I was doubting the finalizers being the culpit) but without success.
Thanks!
- Lenguaje dominante
- C#
- Estrellas
- 783
- Forks
- 80
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
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 microsoft/node-api-dotnet
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
microsoft/node-api-dotnet#484 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
microsoft/node-api-dotnet#481 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 82/100
microsoft/node-api-dotnet#502 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
microsoft/node-api-dotnet#486 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
microsoft/node-api-dotnet#479 ·
Todos los issues de microsoft/node-api-dotnet
Issues similares
-
area/navigationview 🧭 difficulty/starter 🚀 good first issue kind/bug platform/all project/navigation-lifecycle 🧬 triage/untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
unoplatform/uno#24925 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DamianEdwards/ghcp-spend-tray#39 ·
Los mantenedores suelen responder en 1 día
-
copilot documentation
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 2 días
-
[Rust][Flaky Test] multiple_deadlines_fire_in_order asserts a wall-clock gap instead of firing orderAbiertoCI/CD ⚒️ Flaky-tests 🐦
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
valkey-io/valkey-glide#7255 ·
Los mantenedores suelen responder en 3 días
-
bug good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
unoplatform/Uno.Core#99 ·