Bug #907
Linux : Execute using AOZ Viewer crash
Added by Baptiste Pillot over 1 year ago. Updated over 1 year ago.
0%
Description
Crash when I execute using AOZ Viewer, or the AOZ Direct Mode :
Files
Updated by Baptiste Pillot over 1 year ago
- Subject changed from Linux : Execute using AOZ Viewer crash to Linux : Execute using AOZ Viewer crash (B16u25)
Updated by Baptiste Pillot over 1 year ago
- Subject changed from Linux : Execute using AOZ Viewer crash (B16u25) to Linux : Execute using AOZ Viewer crash
- Affected version set to 1.0.0 (B16) u25
Updated by Baptiste Pillot over 1 year ago
Testé ce matin sous un Mint 20 "tout neuf": là ça fonctionne bien.
Le problème survient sur mon Mint 21. Je vais tester avec un nouveau compte utilisateur, pour voir si c'est de là que ça peut venir...
Updated by Baptiste Pillot over 1 year ago
Testé cette après-midi sur Mint 21 "tout neuf" dans une VM.
[X] Lancement en mode AOZ Viewer : ça marche correctement. Il doit donc y avoir quelque chose sur mon PC qui cloche, sans poser problème ici.
[ ] Mode direct : l'application se lance en AOZ Viewer, mais je ne vois pas la ligne de commande où je peux taper en "mode direct". Comparativement, sous Windows, le mode direct ne veut pas se lancer avec un "disponible prochainement".
[ ] Par contre en lancement en AOZ Viewer sous Linux, quand ça marche, je n'ai pas les petits boutons qui sont présents sous Windows : Stop program, Reload the program, Toggle the screen orientation, Toggle Fullscreen, Javascript console, AOZ Debugger.
Updated by Baptiste Pillot over 1 year ago
Du neuf après avoir manipulé et testé ça un peu dans tous les sens :
- Après suppression du dossier et réinstallation le AOZ Viewer veut bien remarcher. Mais au bout de quelques lancements, ou si je met ma fenêtre en plein écran, ou si je l'agrandis... enfin je ne sais pas trop après quoi, mais il suffit de bouger un truc pour que ça ne marche plus... plus moyen on revient à la fenêtre blanche.
- J'arrive à obtenir que AOZ Viewer fonctionne de nouveau en supprimant le contenu de ~/AOZ_Studio/AOZ_Studio/electronUserData. Attention, je dois garder ce dossier (vidé), sinon ça ne remarche plus ! Du coup je dois régulièrement purger ce dossier (et relancer AOZ Studio) pour avoir de nouveau le AOZ Viewer opérationnel.
- Après différents essais, je peux obtenir que AOZ Viewer fonctionne de nouveau en supprimant uniquement le fichier ~/AOZ_Studio/AOZ_Studio/electronUserData/Cookies et en relançant AOZ Studio.
Updated by Baptiste Pillot over 1 year ago
- Status changed from New to Resolved
- Assignee set to Baptiste Pillot
- Target version set to 1.0.0 (B17)
Soumis un patch aujourd'hui.
Si je met dans aoz-viewer.js le this.win.loadURL() dans un setTimeOut(), même sans délai, ça permet de retarder très légèrement l'appel de l'URL, ce qui suffit à ce que ça soit fait après que le serveur web local utilisé par le AOZ Viewer soit lancé (même si je ne sais pas où dans le code ce dernier se lance, toutefois).
En tous cas avec ce setTimeOut je n'arrive plus du tout à reproduire le cas, qui arrivait systématiquement avant.
Je pense qu'il y avait une quasi simultanéité de lancement du serveur local et de l'appel à l'URL sur le serveur local. Si l'URL était appelée plus rapidement que le serveur se lançait, ça plantait l'erreur. Mon setTimeOut() a remis les choses dans l'ordre.
La présence ou l'absence du fichier Cookies devait accélérer (pas de fichier) ou ralentir (fichier présent) le démarrage du serveur web, et permettre qu'il soit disponible - ou non - avant l'appel de l'URL cliente, voilà tout.
Le fait que le code de aoz-viewer.js soit déjà pourri de pleins de setTimeOut fantaisistes par-ci par là me conforte dans cette idée que c'est une solution conforme à la manière de résoudre ce type de problème. Le mieux aurait été de vérifier que le serveur est bien à l'écoute avant de lancer le loadURL, quitte à reporter de nouveau avec un autre setTimeOut, mais si on a une fiabilité suffisante juste en mettant la chose dans l'ordre comme j'ai fait ici, inutile de rajouter du code pour un cas qui n'arrivera jamais. Toutefois si le cas se reproduit, ce sera la solution : vérifier si le serveur écoute, et sinon relancer. Un simple try catch retry later pourra suffire.