J'utilise perdb dans EMACS pour déboguer les scripts PERL (sur Linux). Cela fonctionne bien, jusqu'à ce que je débrouge un script qui fourchette. Si mon script exécute une "fourchette", je reçois ceci:
######### Forked, mais je ne sais pas comment créer une nouvelle TTY. #########
Puisque deux debuggers se battent pour le même tty, l'entrée est sévèrement empêtrée.
Je sais comment activer la sortie dans une fenêtre différente des consoles XTERMS et OS / 2 uniquement. Pour un commutateur manuel, mettez le nom de la TTY créée en $ DB :: fork_ttty ou définissez une fonction dB :: get_fork_tty () renvoyant ceci.
sur des systèmes de type UNIX, on peut obtenir le nom d'une TTY pour la fenêtre donnée en tapant tty et déconnectez la coque de TTY en veille 1000000.
J'aimerais vraiment pouvoir choisir un processus (le parent ou l'enfant) et continuer à déboguer ce processus, tout en permettant à l'autre de continuer sans entrave.
Un objectif prolongé serait un moyen de continuer de manière sans ambiguïté de déboguer les deux les processus, peut-être ouvrir des images supplémentaires dans EMACS pour le contrôle et les fenêtres de code. Mais être capable de bien continuer à déboguer, l'un d'entre eux serait une grosse victoire.
Y a-t-il un moyen de le faire à Perldb? J'ai essayé de suivre la suggestion dans ce message, mais j'ai nulle part avec elle.
ou ai-je besoin d'un autre outil de débogage Perl? Si ce dernier, quel débogueur Perl fournit le meilleur soutien pour le débogage multi-processus?
4 Réponses :
Dans cette situation, configurer les fichiers journaux (avec le PID du processus dans chaque ligne) pourrait bien être la voie à suivre. Bien que pas aussi pratique que le débogueur, il sera peut-être un moyen facile de comprendre ce qui se passe avec votre code.
Si vous allez aller à cet itinéraire, découvrez-le Devel :: Trace :: Fourche .
Si vous avez accès à la console et à un bureau GUI, exécutez le débogueur dans une fenêtre Xterm. Le débogueur Perl fonctionne de manière assez transparente avec XTERMS, car le message d'avertissement va allusion à. À mesure que de nouveaux processus sont créés, le débogueur ouvrira de nouvelles fenêtres Xterm et vous pouvez parcourir l'exécution dans n'importe quel processus de n'importe quel ordre.
Dans les deux cas, effacer le drapeau inhibit_exit code> est utile, pour déboguer des programmes multi-processus. Exécuter P> o inhibit_exit=0
Exécution du débogueur dans une fenêtre Xterm est probablement la solution la plus simple à ce problème, mais Cet article < / a> décrit une approche alternative: il existe une variable non documentée Bien sûr, vous ne voulez probablement pas savoir dur ce type de logique dans votre code, vous pouvez donc créer un module de débogueur que vous utilisez uniquement lorsque vous avez besoin via le drapeau dB :: fork_tty qui peut affecter une TTY particulière pour les processus forcés.
-M Votre commande perl .
Comme il est fort probable que vous sont courir sous un xterm ou similaire, vous pourriez être mordu par la vue plutôt étroite de la vue de Perl Debugger de ce qu'est un "xterm". Il est spécifiquement à la recherche pour la chaîne "xterm". Il veut voir exécuté avec: pour vous assurer qu'il obtient la photo. Je pensais seulement que l'un après dix minutes de grumping au débogueur Perl. Il semble très heureux de frayer des tonnes de fenêtres xterm et ne semble pas très bonne pour les nettoyer quand il sort, par le manière. xterm dans la variable d'environnement . Pas gnome-terminal . Pas xterm-256Color . Just xterm .
Je reçois aussi cette erreur, mais exécutez un programme CLI via @ z = `programme et args`; Ce message n'est jamais arrivé avant tout le débogage. Ce qui se passe? La longueur totale de la chaîne de commande est de 274 caractères. Est-ce un problème sous Ubuntu 18.04?
@Bulrush absolument aucune idée. Poster une nouvelle question.