Dois-je compiler des versions avec des informations de débogage comme «full» ou «pdb-only»?


114

Dans Visual Studio 2010 pour un projet C #, si vous accédez à Propriétés du projet> Générer> Avancé> Informations de débogage, vous avez trois options: aucune, complète ou pdb uniquement. Sur la base de la réponse à cette question , je crois comprendre certaines des différences entre full et pdb-only. Cependant, lequel est le plus approprié pour une version de version? Si j'utilise «full», y aura-t-il des ramifications sur les performances? Si j'utilise "pdb uniquement", est-ce qu'il sera plus difficile de déboguer les problèmes de production?

Quelle est la différence entre "full" et "pdbonly"? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option


Le pdb uniquement ou aucun, toujours pour les versions de version.
leppie

13
@leppie Merci mais je cherche une justification de cette position.
RationalGeek


C'est génial s'il n'y a pas d'impact sur les performances. Qu'en est-il de l'impact sur la mémoire? Si je crée une instance de StackTrace et que je demande des informations sur le fichier, elles doivent provenir des données de symbole pdb. Tous les symboles sont-ils chargés en mémoire au démarrage de l'application? Quelle est l'utilisation approximative de la mémoire? (par exemple, pourcentage de surcharge par rapport à la taille du code.)
yoyo

Réponses:


90

Je construirais avec pdb-only. Vous ne pourrez pas attacher un débogueur au produit publié, mais si vous obtenez un vidage sur incident, vous pouvez utiliser Visual Studio ou WinDBG pour examiner les traces de pile et les vidages de mémoire au moment de l'incident.

Si vous choisissez fullplutôt que pdb-only, vous obtiendrez les mêmes avantages, sauf que l'exécutable peut être attaché directement à un débogueur. Vous devrez déterminer si cela est raisonnable compte tenu de votre produit et de vos clients.

Assurez-vous de sauvegarder les fichiers PDB quelque part afin de pouvoir les référencer lorsqu'un rapport de plantage arrive. Si vous pouvez configurer un serveur de symboles pour stocker ces symboles de débogage, tant mieux.

Si vous choisissez de construire avec none, vous n'aurez aucun recours en cas de plantage sur le terrain. Vous ne pourrez effectuer aucune sorte d'examen après coup de l'accident, ce qui pourrait sérieusement entraver votre capacité à localiser le problème.

Une note sur les performances:

Les deux Robbins John et Eric Lippert ont écrit les messages de blog sur le /debugdrapeau, et ils indiquent tous deux que ce paramètre a zéro impact sur les performances . Il existe un /optimizeindicateur distinct qui dicte si le compilateur doit effectuer des optimisations.


7
@Matt, l' article MSDN sur le commutateur / debug met explicitement en garde contre un impact sur les performances de l'utilisation du paramètre `` complet '':If you use /debug:full, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with /debug:full. We recommend /debug:pdbonly or no PDB for generating release code.
Allon Guralnek

3
@Matt: Si 'full' n'a aucun inconvénient par rapport à 'pdb-only', mais n'a que des avantages, pourquoi existe-t-il même 'pdb-only'? Y a-t-il une raison de l'utiliser sur «plein»? Vous devez également ajouter la correction à l'article MSDN dans la section "Contenu de la communauté".
Allon Guralnek

9
@AllonGuralnek cite l'article lié à John Robbins: La vraie raison: l'histoire. De retour dans .NET 1.0, il y avait des différences, mais pas dans .NET 2.0. Il semble que .NET 4.0 suivra le même modèle. Après avoir vérifié avec l'équipe de débogage CLR, il n'y a aucune différence.
bentayloruk

5
Ce n'est pas vrai. Vous pouvez créer uniquement avec pdb et toujours attacher un débogueur. Je l'ai juste fait pour être sûr.
Mark

2
"Je construirais uniquement avec pdb. Vous ne pourrez pas attacher un débogueur au produit publié" Quelle est votre source d'informations ici? Comme @Mark et moi l'avons noté, cela ne semble pas correct.
MEMark

66

AVERTISSEMENT La documentation MSDN pour le commutateur / debug (dans Visual Studio, il s'agit des informations de débogage) semble être obsolète! C'est ce qu'il a qui est incorrect

Si vous utilisez / debug: full , sachez qu'il y a un impact sur la vitesse et la taille du code optimisé JIT et un petit impact sur la qualité du code avec / debug: full . Nous recommandons / debug: pdbonly ou pas de PDB pour générer le code de version.

Une différence entre / debug: pdbonly et / debug: full est qu'avec / debug: full le compilateur émet un DebuggableAttribute, qui est utilisé pour indiquer au compilateur JIT que les informations de débogage sont disponibles.

Alors, qu'est-ce qui est vrai maintenant?

  1. Pdb uniquement - Avant .NET 2.0, il aidait à enquêter sur les vidages sur incident du produit publié (machines clientes). Mais cela n'a pas permis d'attacher le débogueur. Ce n'est pas le cas avec .NET 2.0. C'est exactement la même chose que Full .
  2. Complet - Cela nous aide à enquêter sur les vidages sur incident et nous permet également d'attacher le débogueur à la version de version. Mais contrairement aux mentions MSDN, cela n'a pas d'impact sur les performances (depuis .NET 2.0). Il fait exactement la même chose que Pdb uniquement .

S'ils sont exactement les mêmes, pourquoi avons-nous ces options? John Robbins (le dieu du débogage de Windows) a découvert qu'ils étaient là pour des raisons historiques.

De retour dans .NET 1.0, il y avait des différences, mais pas dans .NET 2.0. Il semble que .NET 4.0 suivra le même modèle. Après avoir vérifié avec l'équipe de débogage CLR, il n'y a aucune différence.

Ce qui contrôle si le JITter effectue une compilation de débogage est le commutateur / Optimize. <…>

L'essentiel est que vous souhaitez créer vos versions de version avec / Optimize + et l'un des commutateurs / debug afin que vous puissiez déboguer avec le code source.

puis il continue pour le prouver.

Désormais, l'optimisation fait partie d'un commutateur séparé /optimize(dans Visual Studio, cela s'appelle Optimize code).

En bref, quel que soit le paramétrage de DebugInfo pdb-only ou full, nous aurons les mêmes résultats. La recommandation est d'éviter None car cela vous priverait de pouvoir analyser les vidages sur incident du produit publié ou de l'attachement du débogueur.


3
Réponse fantastique! Mes propres enquêtes (comparaison de fichiers générés) montrent les mêmes résultats.
MEMark

@rpattabi Pouvez-vous spécifier la référence que pdbonly et full sont les mêmes? Nous sommes en 2019 et la documentation indique toujours qu'ils sont différents et que les performances seront dégradées. Et VS2019 crée un projet avec Releasele type de débogage de la configuration défini par défaut sur pdbonly.
joe

@joe Il y a une discussion au bas de la documentation MSDN msdn.microsoft.com/en-us/library/8cw0bt21.aspx . Jetez un coup d'oeil. Un contributeur a fait référence à github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/… pour des informations à jour où pdbonly et full sont mentionnés comme étant identiques. (FYI. Je n'utilise plus Windows ou VS. Donc je n'ai pas suivi ce qui se passe là-bas. Mais comme je l'ai examiné, les informations dans ma réponse sont toujours pertinentes et MSDN doc est toujours incorrecte.)
rpattabi

16

Vous ne voudrez que PDB, mais vous ne voudrez pas donner les fichiers PDB aux utilisateurs. Les avoir pour vous-même, en plus de vos binaires, vous donne la possibilité de charger des vidages sur incident dans un débogueur comme WinDbg et de voir où votre programme a réellement échoué. Cela peut être plutôt utile lorsque votre code plante sur une machine à laquelle vous n'avez pas accès.

Le débogage complet ajoute l'attribut [Debuggable] à votre code. Cela a un impact énorme sur la vitesse. Par exemple, certaines optimisations de boucle peuvent être désactivées pour faciliter le pas à pas. De plus, cela a un petit effet sur le processus JIT, car il active le suivi.


Logique. De toute façon, je ne distribue pas vraiment de DLL aux utilisateurs - c'est une application ASP.NET. Mais pouvez-vous améliorer votre réponse et justifier pourquoi vous devriez opter pour "pdb uniquement" ou "complet"? Est-ce un problème de performances?
RationalGeek

@jkohlhepp: Je voudrais ajouter cependant que le débogage des versions de version est un peu délicat car vous perdrez certaines informations (à cause du JIT). Presque toujours, vous ne pourrez pas voir les valeurs des arguments de méthode. Pour contourner ce problème, vous pouvez désactiver temporairement l'optimisation JIT en utilisant ceci .
Ilian Pinzon

Merci Blowdart et merci Ilian Pinzon pour les informations supplémentaires. Je sais que vous ne pouvez pas obtenir un débogage parfait avec le code de version, mais avoir les PDB est mieux que rien.
RationalGeek

L'utilisation du paramètre «complet» n'a pas d'impact sur les performances. Il permet simplement à un débogueur d'être attaché à un processus en cours d'exécution.
Matt Dillard

1
Bonne question sur MSDN Matt, msdn.microsoft.com/en-us/library/8cw0bt21 , en attendant la réponse moi-même.
Luke Hutton

4

Je suis en train d'écrire un gestionnaire d'exceptions non géré et la trace de la pile inclut le numéro de ligne lorsque pdb-only est utilisé, sinon j'obtiens simplement le nom du sous / fonction lorsque je choisis Aucun.

Si je ne distribue pas le .pdb, je n'obtiens pas le numéro de ligne dans la trace de la pile, même avec la version pdb uniquement.

Donc, je distribue (XCOPY déploie sur un LAN) le pdb avec l'exe de mon application VB.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.