Bonjour à tous,
 
J'utilise un script perl test.pl qui va enchaîner une liste de traitement basé sur la manipulation d'objets rédigés sous forme de modules. Je souhaiterais debugger le dernier module écrit. Si je pars en pas à pas du script d'appel et que je descends dans les sous-routines, cela prend beaucoup trop de temps pour atteindre la partie du code qui m'intéresse. Lorsque j'y arrive le debugger m'indique que je suis à :
 
Runtime::tomcat5::Server::doStart(/exploit/ISA/dev/scripts/lib/Runtime/tomcat5/Server.pm:137)
 
Comment puis-je dans le debugger positionner directement un breakpoint à cet endroit pour m'y rendre directement ?
 
Merci d'avance pour vos réponses.

Voir http://debugger.perl.org/580/perldebug.html en ce qui concerne les breakpoints.
Faire d'abord un breakpoint à l'appel de la subroutine, y rentrer, et faire puis un breakpoint a la bonne ligne de cette subroutine devrait coller je pense.
A+,

Merci pour le lien mais je l'avais déjà regardé en fait et je n'arrive pas à mettre en oeuvre ce qui est décrit. Je peux probablement faire ce que tu décris mais c'est également très fastidieux puisque le traitement passse par toute une série d'appel de classe différentes. Idéalement et je pense que ça doit être possible, je voudrais une fois dans mon script d'entrée test.pl en mode debug, ajouter un breakpoint en faisant un truc du genre b Runtime::Server.pm par exemple.

Je peux pas trop vous aider sur ce point, j'utilise très très rarement le débugger perl. En général, un peu de tracage avec Data::Dumper dans la zone ou il y a problème me suffit a débugger ce que j'écris.
b load Runtime::Server.pm (le path doit être trouvable par rapport a la variable @INC de perl) devrait mettre un bp a la première exécution d'une ligne du module.
A ce moment la, b numero_de_ligne devrait mettre un bp a la ligne voulue.
A+,

J'avais testé cette forme également mais sans succès, pas d'erreur lors du passage de la commande mais si je laisse le script se dérouler avec un "c" dans le debugger, ce dernier ne s'arrête pas dans le module :-( Merci pour tes réponses en tous cas.

Euh oui, c'est une erreur de ma part:
C'est pas  
b load Runtime::Server.pm  
mais
b load Runtime/Server.pm (un vrai nom de fichier)
voire le nom absolu du fichier, si le nom relatif du fichier ne colle pas.
S'il s'y arrête pas, c'est probablement parce que le nom de fichier donné n'est pas bon (ou pas résolu par rapport à @INC).
A+,

Y a du mieux en effet avec un chemin absolu. Quand je passe la commande b load /exploit/ISA/sylvain/dev/scripts/lib/Runtime/tomcat5/Server.pm, le debugger me répond bien :
Will stop on load of `/exploit/ISA/sylvain/dev/scripts/lib/Runtime/tomcat5/Server.pm'.
Bon cela dit, je l'avais aussi ce message avec l'ancienne syntaxe.
Et effectivement le debugger s'arrête bien dans la classe qui charge la classe qui m'intéresse. Le problème c'est que je suis encore loin d'être dans mon code et que celui-ci ne soit invoqué. Peut être que ce n'est tout simplement pas possible que le debugger s'arrête uniquement quand le code du module s'exécute...

C'est ce que j'ai dit: Une fois ce module chargé vous allez pouvoir poser un nouveau break point a la ligne qui vous intéresse, ou bien a la subroutine qui vous intéresse.
A+,

Je pense qu'on tient le bon bout, cela fonctionne effectivement, je fais donc  
b load /exploit/ISA/sylvain/dev/scripts/lib/Runtime/tomcat5/Server.pm,  
je laisse le script se dérouler et il s'arrête alors bien au chargement de cette classe. Je peux alors effectivement mettre un breakpoint sur une ligne de cette classe avec un simple b 138 par exemple ou un b doStart si je veux être sur une sous-routine. Puis je laisse de nouveau le script se dérouler et il s'arrêté bien à la ligne demandée sur la classe que je voulais.  
 
Merci beaucoup pour ton aide