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...