Ipython: Impossible d'interrompre des boucles infinies dans le bloc-notes

Créé le 13 janv. 2013  ·  29Commentaires  ·  Source: ipython/ipython

J'ai récemment donné une introduction à la programmation Python à l'atelier sur la génomique. Pour le tutoriel, nous avons utilisé l'interface notebook et elle a été très bien accueillie (merci !). Lors de la discussion sur les boucles, j'ai demandé aux étudiants de convertir un exemple de boucle for en boucle while. Au cours du processus, de nombreux étudiants ont créé des boucles infinies. Pour certains de ces étudiants, Firefox a planté. Le correctif consistait à tuer le serveur de bloc-notes et à tuer le navigateur. Tous les étudiants utilisaient des machines virtuelles basées sur Ubuntu et Firefox comme navigateur. Si cela peut aider, je peux obtenir plus de détails sur les systèmes et déterminer si je peux recréer ce comportement sur ma copie de la machine virtuelle.

needs-info

Commentaire le plus utile

Je pense que l'un de nous doit trouver un simple ordinateur portable qui reproduit ce problème, au moins sur certains systèmes.

while True:
    print "foo"

Cela fait que Firefox utilise 100% du processeur et ne répond pas de quelque manière que ce soit. Tuer Firefox et le processus IPython est le seul moyen de récupérer le système.

Ipython 3.0.0
Firefox 42.0
Linux 3.13.0-24-générique

Tous les 29 commentaires

Est-ce que par hasard celui qui plante produirait une sortie et non celui qui n'a pas planté le navigateur?
(vous devriez avoir un kill kernel dans un menu)

Nous pourrions probablement avoir un délai d'expiration de l'opt-in de sécurité qui tue le serveur si le noyau reste occupé trop longtemps, ou si le frontend reçoit trop d'entrées

Je pense qu'il y a deux problèmes ici:

  • Interrompre une boucle infinie est parfaitement possible. Dans le menu Noyau, cliquez sur interrompre.
  • Si votre boucle imprime quelque chose à chaque étape, cela produira une énorme quantité de sortie, ce qui pourrait causer des problèmes au navigateur. Voir aussi le numéro 1975.

@Carreau il n'y a pas eu de sortie

@takluyver le menu du noyau n'était pas réactif. Cela se produisait avec des boucles qui s'imprimaient et des boucles qui ne s'imprimaient pas.

Pouvez-vous donner un exemple de boucle où cela ne fonctionne pas ?

Le 13 janvier 2013 à 16h11, Daniel McDonald [email protected] a écrit :

@Carreau https://github.com/Carreau il n'y a pas eu de sortie

@takluyver https://github.com/takluyver le menu du noyau n'était pas
sensible. Cela se produirait avec des boucles qui s'imprimaient et des boucles qui
n'imprimaient pas.


Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/ipython/ipython/issues/2781#issuecomment -12195606.

Un algorithme d'anagramme naïf/horrible lorsque les mots ne sont pas des anagrammes les uns des autres

from random import shuffle 
word1 = list("quietx")
word2 = list("quite")
while word1 != word2:
    shuffle(word1)

Je viens de tester et je peux interrompre celui-ci sans problème sur Firefox et Ubuntu. Pouvez-vous le répliquer de manière fiable sur votre système ?

Je ne peux pas le reproduire sur mon système. Je vais rechercher les utilisateurs qui ont rencontré le problème et réexécuter sur leurs systèmes. Les sessions de l'atelier reprennent demain matin - l'atelier est en Europe et aujourd'hui est un jour de congé - donc il me faudra un peu de temps avant de pouvoir revenir là-dessus.

Je ne suis plus en mesure de tester cela et n'ai pas pu assurer le suivi au
atelier. Étant donné que je ne peux pas reproduire le problème, ni personne d'autre,
laisse la craie jusqu'à un coup de chance.

Merci encore pour la réponse rapide et je m'excuse de perdre du temps sur ce

Le dimanche 13 janvier 2013 à 9h57, Thomas Kluyver [email protected] a écrit :

Je viens de tester, et je peux interrompre celui-là sans problème sur Firefox
& Ubuntu. Pouvez-vous le répliquer de manière fiable sur votre système ?


Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/ipython/ipython/issues/2781#issuecomment -12196271.

Pas de soucis. N'hésitez pas à rouvrir si vous trouvez un moyen de reproduire le bug.

Je reçois cela tout le temps dans le cahier IPython en chrome (et je viens de le tester dans firefox, et il "a réussi", c'est-à-dire qu'il s'est écrasé). Je _pense_ que cela arrive à chaque fois que j'ai une boucle infinie qui s'imprime fréquemment. C'est un problème pour moi, car je mets souvent des instructions d'impression pour déboguer, et dans ce cas, je perds le code qui était censé corriger mon bogue à cause d'un plantage.

Voici le code que j'ai utilisé pour le faire planter:

importer numpy en tant que np
x = np.tableau([0,1,2,3,4])
it = np.nditer(x,flags=['f_index'])
tant que ce n'est pas le cas.terminé :
imprimez-le.index

ça m'arrive aussi...
D'abord, le navigateur ne répond plus et plus tard, je constate que tout le système se bloque. Je suis obligé de faire un hard-reset.
J'utilise Ubuntu avec xfce desktop / firefox.
Si cela peut être utile, je serais prêt à partager tout autre détail dont vous pourriez avoir besoin pour résoudre ce problème...
@minrk

Ce problème semble toujours là !

Je peux exécuter "l'interruption" ou "Redémarrer" à partir du menu du noyau, mais cela n'a pas du tout pris effet. l'icône en cours d'exécution s'affiche toujours sous la forme d'une boule noire.

Même si je redémarre l'ordinateur, après avoir cliqué à nouveau sur le bloc-notes, il y restera en boucle pour toujours !

J'utilise MacBook avec ipython 2.2.0 installé.

J'ai également eu ce problème: bloc-notes ipython suspendu dans le navigateur et incapable de récupérer à l'aide du noyau d'interruption. En plus des erreurs de boucle, cela semble se produire avec n'importe quel processus suspendu, par exemple si une requête Internet dans une fonction se bloque pour des raisons de réseau.

Ma question est la suivante: existe-t-il un moyen d'accéder au noyau sous-jacent à partir de la ligne de commande? Je lance ipython notebook à partir d'un terminal, et pour le moment ma solution consiste à interrompre le clavier de ce terminal, ce qui arrête complètement le noyau.

J'ai aussi ce problème critique . Cela semble être lié aux boucles en effet. Cela m'évite de faire de longues simulations ou analyses de données, ce qui veut dire : je suis foutu...

Je ne sais pas si c'est lié mais j'ai remarqué qu'une fois qu'il se bloque, l'hyperthreading semble s'effondrer en un seul processeur qui fonctionne toujours. Vous pouvez le voir en utilisant htop , par exemple. Au début, il m'a semblé que l'hyperthreading (que les bibliothèques numpy -> BLAS exploitent sur ma machine) était celui qui plantait et que tout fonctionnait lentement, mais ensuite j'ai essayé d'interrompre et je n'ai pas eu de chance et donc je réalisé que c'était le noyau IPython qui venait juste de se bloquer.

Ce problème ne m'est jamais arrivé lorsque:

  • J'utilisais une machine plus ancienne (mais toujours très similaire, juste moins de RAM et de processeurs)
  • J'utilisais l'ancien ipython <3.0
  • Je ne travaillais pas sur un notebook IPython distant

Mes suppositions éclairées sont:

  • problème avec la prise quelque part ...
  • Les backends de threading matplotlib sont en train de gâcher <-- mais c'est juste parce qu'ils le font presque toujours, mieux vaut y mettre le pari;)

Lorsque le problème survient, je redémarre simplement le noyau à partir de l'interface Web et je refait ce que je faisais ...

EDIT: il m'est également difficile de le reproduire mais j'ai remarqué que si je n'utilise pas BLAS, par exemple si je n'utilise pas le produit scalaire de numpy, le problème n'apparaît pas, même si je devrais faire d'autres tests pour vérifier cela.

Je vois aussi ce problème assez fréquemment et il est difficile à résoudre - s'il y a beaucoup de données qui prennent du temps à traiter dans le noyau, il peut être assez pénible de tout tuer et de forcer un redémarrage. Certainement pas un bug imaginaire :)

J'ai aussi ce problème sur OSX + chrome.

@minrk , je pense que cela vaut peut-être la peine de rouvrir. Je n'ai pas suffisamment de privilèges pour simplement rouvrir avant de créer un nouveau problème.

À partir de la CLI, il semble que le fait d'appuyer sur le bouton d'arrêt fasse quelque chose, mais le portable reste complètement insensible.

[I 15:26:22.224 NotebookApp] Kernel interrupted: edee0497-b340-43fd-be77-1ad67e5170ee
[I 15:26:32.197 NotebookApp] Kernel interrupted: edee0497-b340-43fd-be77-1ad67e5170ee
[I 15:26:42.688 NotebookApp] Saving file at /Untitled.ipynb
[I 15:27:30.993 NotebookApp] Kernel interrupted: edee0497-b340-43fd-be77-1ad67e5170ee
[I 15:27:35.605 NotebookApp] Kernel interrupted: edee0497-b340-43fd-be77-1ad67e5170ee
[I 15:28:43.999 NotebookApp] Saving file at /Untitled.ipynb
[I 15:29:28.038 NotebookApp] Kernel interrupted: edee0497-b340-43fd-be77-1ad67e5170ee

Je pense que l'un de nous doit trouver un simple ordinateur portable qui reproduit ce problème, au moins sur certains systèmes. Sinon, ce ne sera probablement pas réparable.

Je constate également ce problème.

Je pense que l'un de nous doit trouver un simple ordinateur portable qui reproduit ce problème, au moins sur certains systèmes.

while True:
    print "foo"

Cela fait que Firefox utilise 100% du processeur et ne répond pas de quelque manière que ce soit. Tuer Firefox et le processus IPython est le seul moyen de récupérer le système.

Ipython 3.0.0
Firefox 42.0
Linux 3.13.0-24-générique

je peux reproduire avec
ipython 3.2.0
Python 2.7.10
Version chromée 46.0.2490.86 (64 bits)
OSX 10.10.5

Assez énorme ennui pour moi aussi. Je dois souvent tuer tout le serveur d'ordinateurs portables avec chrome à cause de ce problème. Je peux arriver au point où je clique sur le bouton d'interruption du noyau et il se met en surbrillance comme s'il avait été cliqué, mais quelque chose, quelque part, ne reçoit pas le message d'arrêt.

Ma première impression est que c'est un problème avec le moteur de rendu de texte de chrome, mais je sais peu de choses sur la façon dont cela fonctionne.

Un autre exemple de lenteur est lorsqu'un matplotlib relativement grand vient au premier plan après l'avoir fait défiler. Le bloc-notes entier devient extrêmement nerveux pendant 4 à 5 bonnes secondes.

Pour ce que ça vaut, j'utilise une machine assez costaud, donc c'est particulièrement bizarre que jupyter puisse mettre toute ma machine à genoux.

9/10, cela arrive par accident, donc ce n'est pas aussi simple que de l'appeler un bogue d'erreur utilisateur.

Je viens d'avoir ce problème pour moi (ou du moins il correspond au profil décrit ci-dessus). Je ne pouvais pas faire en sorte que la fenêtre soit régulièrement réactive, mais _je pouvais_ faire une copie très lente du presse-papiers de toute la page, ce qui m'a permis de conserver mes modifications récentes du code.

Pas une solution au problème, mais un moyen potentiel d'atténuer ses conséquences.

J'ai eu le même problème aujourd'hui et dans le passé, sous Linux Mint (18.0) et firefox. C'était un générateur count() très simple, mais j'étais en train de jouer avec __getitem__ et, d'une manière idiote, j'ai mis une impression sur la clé.

Les dernières versions de nos packages implémentent la limitation de la sortie, ce qui devrait atténuer les problèmes liés aux grandes quantités de sortie qui ralentissent le navigateur.

Fermeture car ce problème n'est pas dans IPython lui-même et s'il reste problématique et pertinent, il doit être ouvert sur le bon référentiel. Cela permettra de garder sous contrôle le nombre de problèmes ouverts sur le référentiel IPython.

N'hésitez pas à continuer à commenter ou à rouvrir si nécessaire.

Merci.

@Carreau , avez-vous un référentiel suggéré (ou cela n'a-t-il tout simplement pas été reporté là où les problèmes de bloc-notes sont suivis ...) ?

Cela devra être migré vers jupyter/notebook ou jupyterlab/jupyterlab. Probablement le deuxième s'il affecte également jupyterlab.

Cette page vous a été utile?
0 / 5 - 0 notes