web-dev-qa-db-fra.com

Comment contourner une erreur de mémoire avec karma & phantomjs

Nous effectuons des tests avec karma et phantomjs la semaine dernière, nos tests ont mystérieusement commencé à planter phantomJS avec une erreur de -1073741819.

Basé sur ce thread pour Chutzpah il semble que le code indique un échec de la mémoire native avec PhantomJS.

Après des recherches approfondies, nous constatons régulièrement un crash fantôme autour de 750 Mo de mémoire.

Y a-t-il un moyen de configurer Karma pour qu'il ne se heurte pas à cette limite? Ou un moyen de lui dire de vider fantôme?

Nous avons seulement environ 1200 tests à ce jour. Nous en sommes à environ un quart de notre projet. Par conséquent, 5000 tests d’interface utilisateur ne semblent pas hors de question.

phantomjskarma-runnerkarma-jasmine
20
taylonr

Grâce au phénomène StackOverflow consistant à poser une question et à découvrir rapidement une réponse, nous avons résolu ce problème en ajoutant des tâches gulp. Avant, nous n'exécutions que karma start en ligne de commande. Cela a entraîné une seule instance de phantomjs qui s'est écrasée lorsque 750 Mo ont été atteints.

Nous avons maintenant une commande gulp pour chacune de nos sections de tests, par exemple. gulp common-tests et gulp admin-tests et gulp customer-tests

Ensuite, un seul gulp karma qui exécute chacun de ces groupes. Cela permet à chaque commande gulp d'avoir sa propre instance de fantôme et donc de rester en dessous de ce seuil.

9
taylonr

Nous avons rencontré un problème similaire. Votre approche est intéressante et représente certainement une étape supplémentaire. Cependant, soyez prêt à y faire face plus tard. 

J'ai fait des recherches et trouvé la cause de la croissance de la mémoire (du moins dans notre cas). Il s'avère que lorsque vous utilisez:

   beforeEach(inject(SomeActualService)){ .... }

la mémoire occupée par SomeActualService ne sera pas libérée à la fin du bloc describe et si vous avez plusieurs fichiers de test où vous injectez le même service (ou d'autres objets injectables), plus de mémoire lui sera allouée. 

J'ai quelques idées sur la façon d'éviter cela: 1. créez des objets fictifs et n'utilisez jamais inject pour obtenir des objets réels, sauf si vous êtes dans le test qui teste ce module. Cela nécessitera l'écriture de tonnes de code supplémentaire. 2. Créez votre propre suivi (uniquement pour les tests) pour les objets injectables. De cette façon, ils ne peuvent être chargés qu'une seule fois et réutilisés entre les fichiers de test.

Oubli de mentionner: Nous utilisons un angulaire 1.3.2, Jasmine 2.0 et avons résolu ce problème autour de 1000 tests.

8
Simon N

Je rencontrais également ce problème après environ 1037 tests sur Windows 10 avec PhantomJS 1.9.18 . 

Il apparaîtrait comme ERROR [launcher]: PhantomJS crashed. après que le RAM du processus dépasse environ 800 à 850 Mo.

Il semble y avoir une solution temporaire ici:

Vous l'installez via npm install karma-phantomjs2-launcher --save-dev

Mais alors besoin de l'utiliser dans karma.conf.js via 

config.set({
    browsers: ['PhantomJS2'],
    ...
});

Cela semble exécuter le même ensemble de tests en utilisant uniquement entre 250 et 550 Mo RAM et sans planter.

Notez que ce correctif fonctionne immédiatement avec Windows et OS X, mais pas sous Linux (les fichiers binaires PhantomJS2 ne démarreront pas). Cela affecte les poussées vers Travis CI.

Pour contourner ce problème sous Debian/Ubuntu:

Sudo apt-get install libicu52 libjpeg8 libfontconfig libwebp5

7
Splaktar

C'est un problème avec PhantomJS. Selon une autre source , PhantomJS n’exécute le ramasse-miettes que lorsque la page est fermée et cela ne se produit qu’après l’exécution de vos tests. Les autres navigateurs fonctionnent correctement car leurs éboueurs fonctionnent comme prévu.

Après avoir passé quelques jours sur le sujet, nous avons conclu que la meilleure solution consistait à scinder les tests en groupes. Nous avons eu grogné créer un profil pour chaque répertoire de manière dynamique et créé une commande qui exécute tous ces profils. À toutes fins utiles, cela fonctionne de la même manière.

5
Nicolas Bouliane

Nous avons eu un problème similaire sur linux (Ubuntu), qui s’est avéré être la quantité de segments de mémoire que le processus peut gérer:

$ cat /proc/sys/vm/max_map_count
65530

Puis lancez ceci:

$ Sudo bash -c 'echo 6553000 > /proc/sys/vm/max_map_count'

Notez que le nombre a été multiplié par 100. Ceci modifiera les paramètres de la session. Si cela résout le problème, vous pouvez le configurer pour toutes les sessions futures:

$ Sudo bash -c 'echo vm.max_map_count = 6553000 > /etc/sysctl.d/60-max_map_count.conf'
2
Elad Tabak

Répondre à une vieille question, mais j'espère que cela aidera ...

J'ai un processus de construction qu'un travail de CI exécute dans une boîte de linux seulement de ligne de commande. Donc, il semble que PhantomJS soit ma seule option. J'ai rencontré ce problème de mémoire localement sur mon Mac, mais cela ne se produit généralement pas sous Linux. Ma solution consistait à ajouter une autre commande de test à mon package.json pour exécuter karma à l'aide de Chrome et à l'exécuter localement pour exécuter mes tests. Lorsque relevé, Jenkins lancait la commande de test normale en exécutant PhantomJS.

Installez ce plugin: https://github.com/karma-runner/karma-chrome-launcher

Ajoutez ceci à package.json

"test": "karma start", "test:chrome": "karma start --browsers Chrome"

0
cgsd