Discussion :

[Klaim]

Bonjour!

(Je ne suis pas sur que ce soit le bon forum pour cette question...)

J'aimerai savoir quelle pratique vous mettez en place pour debugger une application qui est divisée en plusieurs processus instanciés par un premier processus, avec visual studio 2008?

Un simple test avec un breakpoint dans un processus enfant (le parent étant le premier processus) me permet de voir que les processus enfants ne sont pas pris en compte en mode Debug (config par défaut) en C++ natif dans Visual Studio 2008 (au moins).
Il y a visiblement l'option d'attacher un processus au debugger au cours du debuggage mais 1) ça doit visiblement être fait "à la main" à chaque debuggage et 2) ça ne semble pas marcher dans mon simple test, le breakpoint se trouvant dans une boucle où je log du texte pour m'assurer que le processus est bien en train de l'executer mais il n'y a jamais d'arret sur ce breakpoint.

Donc j'aimerai connaitre vos pratiques parcequ'une recherche sur le net ces deux dernières soirées ne m'ont pas apris grand chose de plus là dessus.
Ou peut-être y a-t-il des références?

Merci de votre attention

(Hmmm c'est marrant le merveilleux monde du multiprocess m'apparait tout aussi rébarbatif que très motivant, je dois être un peu maso XD)

[Klaim]

Pour l'instant je suis parti dans cette direction :

J'ai donc une application cliente qui peut lancer un processus serveur (sur la même machine donc).
Uniquement dans ce cas, je met en place quelques informations partagées (via boost::interprocess).

Pour tester, je suis en train de faire en sorte que le serveur puisse aussi être lancé seul (avec les bons paramètres) comme un serveur dédié. De cette manière je peu régler visual studio de manière à lancer le serveur en débug à chaque fois que je lance le client.

Ca me pose problème dans le cas ou je veux que le client décide des paramètres de lancement du serveur mais je ne trouve pas d'autre moyen d'avoir automatiquement les deux processus en debug.

Si je ne trouve pas mieu je me contenterai de logs, mais bon

[Mac LAK]

Il n'y a pas de problèmes sous Visual pour attacher plusieurs processus en même temps au débugger, simplement il te faut t'assurer qu'ils soient tous en mode Debug, et que VS aie les symboles / sources sous le coude. Par contre, par défaut, VS ne s'attache JAMAIS aux processus engendrés (et heureusement, d'ailleurs...).

Attention, par contre, si tu as déjà déployé / déplacé tes exécutables : il est fréquent que l'on ne lance pas l'exécutable que l'on croit, et que l'on arrive donc dans un cas où les breakpoints et/ou les modifications ne sont apparemment pas prises en compte. En général, c'est que l'on a lancé le "mauvais" exécutable.

Ce que tu peux faire, notamment via une compilation conditionnelle (ex : "ENABLE_AUTO_DEBUG"), c'est ajouter un truc dans ce genre au début de ton main, dans TOUS tes programmes impliqués dans le debug :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#ifdef _DEBUG
    #ifdef ENABLE_AUTO_DEBUG
        if (!IsDebuggerPresent())
            DebugActiveProcess(GetCurrentProcessId());
    #endif
#endif

(Liens MSDN : IsDebuggerPresent et DebugActiveProcess)


Ainsi, tu vas attacher automatiquement tes processus au débugger (normalement, Visual Studio si ta machine est correctement configurée) si tu as compilé avec la définition ENABLE_AUTO_DEBUG ET que tu es en mode Debug. En mode Release, ou sans cette nouvelle macro, tu devras continuer d'attacher manuellement chaque processus.

Bon, ça demande peut-être à être peaufiné, là c'est juste une base de réflexion.

[Klaim]

Ah excellent, merci!
C'est exactement le genre de chose que je cherchais mais ça m'étonne que je n'ai rien trouvé, surtout que je suis passé par la msdn... Peut être parceque j'utilisisais principalement le mot clé "process" dans ma recherche.

Je vais essayer en rentrant du boulot!

Pour l'executable effectivement il est déplacé, par contre le mode debug doit se lancer pour l'executable déplacé (pour vérifier que ça marche bien dans le "dossier final").
J'arrive bien a faire marcher le mode debug quand je lance le serveur séparément, les breakpoints marchent, donc reste a tester ta dernière suggestion.

[Mac LAK]

De rien. En fait, pour trouver ça efficacement sur MSDN, il faut savoir qu'une API de debug existe dans Windows (Debugging and Error Handling)... Sinon, tu vas tomber sur la doc de l'API de gestion des processus / threads qui, si elle est effectivement très utile (voire indispensable !), n'aide absolument pas pour le problème que tu rencontres.

Pour info, tu as aussi les Debug Routines qui existent, si tu en as besoin, qui sont des routines majoritairement axées sur le debug des allocations dynamiques.

Pour l'executable effectivement il est déplacé, par contre le mode debug doit se lancer pour l'executable déplacé (pour vérifier que ça marche bien dans le "dossier final").
J'arrive bien a faire marcher le mode debug quand je lance le serveur séparément, les breakpoints marchent, donc reste a tester ta dernière suggestion.

Je ne saurais trop te conseiller de "sortir" l'exécutable à son emplacement final, au moins en mode Debug, via la propriété "Répertoire de sortie" de ton projet (onglet "Général").
Vérifie également consciencieusement le "Répertoire de travail" de l'onglet "Débogage", toujours pour cet exécutable.
Tentes bien la manipulation suivante : efface l'exécutable que tu crois lancer, et vérifie si le lancement automatique échoue bien. Si oui, c'est OK, tu as "le bon". Sinon, il y a un problème de copie.

Si tu as posé ton BP dans une DLL de ton programme, vérifie qu'elle n'existe pas dans un autre répertoire : si une application a déjà chargé en mémoire cette DLL, ce sera cette copie qui sera utilisée, quoi qu'il arrive, et non pas celle que tu viens de recompiler.

[Klaim]

Je ne saurais trop te conseiller de "sortir" l'exécutable à son emplacement final, au moins en mode Debug, via la propriété "Répertoire de sortie" de ton projet (onglet "Général").
Vérifie également consciencieusement le "Répertoire de travail" de l'onglet "Débogage", toujours pour cet exécutable.
Tentes bien la manipulation suivante : efface l'exécutable que tu crois lancer, et vérifie si le lancement automatique échoue bien. Si oui, c'est OK, tu as "le bon". Sinon, il y a un problème de copie.

Si tu as posé ton BP dans une DLL de ton programme, vérifie qu'elle n'existe pas dans un autre répertoire : si une application a déjà chargé en mémoire cette DLL, ce sera cette copie qui sera utilisée, quoi qu'il arrive, et non pas celle que tu viens de recompiler.

Oui ne t'inquiète pas il n'y a pas de souci de ce coté là :
- avant la compilation de l'executable principal, un dossier "final" (dont le nom dépent de la build) est réinitialisé (complètement détruit puis reconstruit des dossiers a vide) -- via un script;
- a la fin du link, un script va prendre les fichiers voulus (listés dans des fichiers textes, séparés par mode de compilation) et les mettre dans les bons dossiers du dossier "final";
- tous les projets (dll et exe) ont pour paramettres de debuggage le context du dossier "final" et l'executable qu'il contient;

Ce qui fait que quel que soit la build, je debug toujours avec le context final. Les breakpoints marchent bien dans tous les cas. J'ai beaucoup testé en virant des exe ou en remplacant par des versions release, on voit tout de suite le problème si ya eu une manipulation "a la main" vu que ça crash. Les scripts marchent a tous les coups heureusement. J'ai mis pas mal de temps a les mettre en place pour me simplifier la vie d'ailleurs (parceque je bosse tout seul sur ce projet et que dans le futur je veux pas que des devs se prennent la tete avec comment builder tout ça, donc ça marche partout normalement).

Le seul problème c'est que ça fait beaucoup d'effacement/réécriture de dossiers et fichiers par jour... je devrais ptete vérifier voir si ça a pas un impacte que le disque dur...

[Klaim]

Bon, la fonction retourne ERROR_SUCCESS mais je ne vois rien dans le debugger quand le serveur est lancé par le client, ni les breakpoints, ni le process.

Je me dit qu'il doit y avoir quelque chose de manquant... pour l'instant je cherche dans les autres fonctions de debug voir.

Edit :

Rien de ce que j'ai tenté jusqu'ici ne marche. Après une autre recherche je suis tombé sur ça : http://codereflect.com/2009/09/20/ho...visual-studio/

Qui m'amène à ça : http://dev.chromium.org/developers/how-tos/debugging

C'est pas une solution super super, mais je vais peut être tester.

Edit 2 :

Ok, alors j'arrive a utiliser mon breakpoint dans le serveur lancé par le client uniquement si je "force" l'"Attach to: Native code" à la main.

La macro de google n'a pas l'air de bien marcher après légère modification (le nom du processus). Je suis en train de la modifier voir.

[Klaim]

La macro de google n'ayant pas l'air de fonctionner, je me suis tourné vers la solution décrite ici : http://msdn.microsoft.com/en-us/library/a329t4ed.aspx

Ce n'est malheureusement pas une bonne solution pratique car :
1. L'ecran s'affichant au lancement du processus me demande d'ouvrir une nouvelle instance d'un des Visual Studio installés : aucun moyen d'utiliser l'instance déjà en cours avec le debugger qui tourne déjà.
2. Une fois l'instance de VS ouverte, il n'y a aucune infos relative aux sources, même si le dossier de l'executable contient le .pdb.

Donc en gros ça ne me sert a rien.

Pour l'instant la seule méthode a peu près efficace que j'ai trouvé est d'attacher le processus à la main, après avoir fait tourner un code spécifique qui empêche le serveur de tourner correctement jusqu'a ce qu'on l'ai attaché au debugger. C'est à mon avis une solution bancale.

Si quelqu'un a une autre solution a suggérer, je suis preuneur.

EDIT>
Alors, j'ai essayé voir de mettre un "debug break" (actuellement implémenté par l'appel ::__debugbreak(); chez moi) au départ du main de l'aplication enfant server et ça me fait le même comportement que la solution MSDN d'au dessus SAUF QUE je vois les sources debuggées. C'est dommage qu'il ouvre un visual studio différent pour ça mais visiblement il se base sur le nom de la solution ouverte pour détecter si le visual studio ouvert correspond à l'executable... je me demande si il n'y a pas un paramettre quelque part pour corriger ça.
Parceque là c'est pas mal, je peux enfin vraiment debugger (après que la fenetre de dialogue soit traitée -- mais je peux mettre un comportement par défaut) le processus enfant vu que j'ai les sources, mais pas toutes les sources, seulement celles concernées par break.