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.