2008-09-25 8 views
44

J'ai écrit du code avec beaucoup de récursion, ça prend pas mal de temps à compléter. Chaque fois que je « pause » la course à regarder ce qui se passe j'obtenir:Que fait "Impossible d'évaluer l'expression car le code de la méthode en cours est optimisé." signifier?

Impossible d'évaluer l'expression car le code de la méthode actuelle est optimisée.

Je pense que je comprends ce que cela signifie. Cependant, ce qui me laisse perplexe, c'est qu'après avoir atteint le pas, le code n'est plus "optimisé", et je peux regarder mes variables. Comment cela peut-il arriver? Comment le code peut-il aller et venir entre le code optimisé et non optimisé?

+0

Avez-vous trouvé une solution de contournement pour ce problème? –

+2

Je ne crois pas que la réponse choisie soit utile. Lorsque vous avez une chance, vérifiez la réponse laissée quelques mois plus tard par "Personne". Cela aidera ceux qui cherchent à résoudre votre question initiale. – Catskul

+3

Je déboguais en mode Release (rougir). La réponse de Lamar m'a fait vérifier. – mayu

Répondre

26

Le débogueur utilise FuncEval pour vous permettre de "regarder" les variables. FuncEval requiert que les threads soient arrêtés dans le code managé à un point sécurisé GarbageCollector. La "pause" manuelle de l'exécution dans l'EDI entraîne l'arrêt de tous les threads dès que possible. Votre code hautement récursif aura tendance à s'arrêter à un point dangereux. Par conséquent, le débogueur est incapable d'évaluer les expressions.

Appuyez sur F10 pour passer au prochain point de sécurité Funceval et activer l'évaluation de la fonction. Pour plus d'informations, consultez la section rules of FuncEval.

+6

Je me suis demandé à ce sujet moi-même, il serait bon de résumer les points saillants de l'article de blog dans votre réponse. – Joe

+0

Ce lien est vraiment intéressant. – Lamar

+0

Est-ce que ce blog posté a pointé une solution ou simplement expliqué le problème? –

25

Vous essayez probablement de déboguer votre application en mode édition au lieu du mode débogage, ou vous avez des optimisations activées dans vos paramètres de compilation. Lorsque le code est compilé avec des optimisations, certaines variables sont jetées dès qu'elles ne sont plus utilisées dans la fonction, ce qui explique pourquoi vous recevez ce message. En mode débogage avec les optimisations désactivées, vous ne devriez pas avoir cette erreur.

+1

Non, je n'essaye pas de déboguer une application qui a été construite en mode release. –

+0

"ou vous avez des optimisations activées dans vos paramètres de compilation" <- aussi ce n'est pas le cas? – Biri

+5

Correct, pas d'optimisations non plus. –

-1

Je crois que ce que vous voyez est le résultat des optimisations - parfois une variable sera réutilisée - en particulier celles qui sont créées sur la pile. Par exemple, supposons que vous ayez une méthode qui utilise deux entiers (locaux). Le premier entier est déclaré au début de la méthode et est utilisé uniquement comme compteur pour une boucle. Votre second entier est utilisé après que la boucle a été complétée, et il stocke le résultat d'un calcul qui est ensuite écrit dans le fichier. Dans ce cas, l'optimiseur PEUT décider de réutiliser votre premier entier, en sauvegardant le code nécessaire pour le second entier. Lorsque vous essayez de regarder le second entier au début, vous obtenez le message que vous posez à propos de "Impossible d'évaluer l'expression". Bien que je ne puisse pas expliquer les circonstances exactes, il est possible que l'optimiseur transfère plus tard la valeur du second entier dans un élément de pile séparé, ce qui vous permet d'accéder à la valeur du débogueur.

44

Alors que la ligne Debug.Break() est au-dessus de la callstack, vous ne pouvez pas évaluer les expressions. C'est parce que cette ligne est optimisée. Appuyez sur F10 pour passer à la ligne suivante - une ligne de code valide - et la montre fonctionnera.

+2

Ceci est la réponse. Espérons qu'il sera finalement marqué comme tel. – Catskul

+2

La question était "qu'est-ce que cela signifie" pas comment puis-je résoudre ce problème. –

+7

Mes deux premières phrases répondent à cette partie aussi. –

1

Avait le même problème mais était capable de le résoudre en désactivant le recouvrement des exceptions dans le débogueur. Cliquez sur [Débogage] [Exceptions] et définissez les exceptions sur "Non-géré par l'utilisateur".

Normalement, je l'ai éteint, mais il est parfois utile.Je dois juste me rappeler de l'éteindre quand j'ai fini.

2

Recherchez un appel de fonction avec de nombreux paramètres et essayez de réduire le nombre jusqu'à ce que le débogage revienne.

7

Cela m'a rendu fou. J'ai essayé d'attacher avec le code managé et natif - pas d'aller.

Cela a fonctionné pour moi et j'ai enfin pu évaluer toutes les expressions:

  • Allez dans Projet/Propriétés
  • Sélectionnez l'onglet Générer et cliquez sur avancée ...
  • Assurez-vous Déboguer Info est mis à "plein" (pas pdb seulement)
  • Déboguez votre projet - voila!
1

J'ai rencontré ce problème lors de l'utilisation de VS 2010. La configuration de ma solution a été sélectionnée (Débogage). J'ai résolu cela en décochant la propriété Optimiser le code sous les propriétés du projet. Projet (clic droit) => Propriétés => Construire (onglet) => décocher Optimiser le code

0

Dans mon cas j'avais 2 projets dans ma solution et exécutais un projet qui n'était pas le projet de démarrage. Lorsque j'ai modifié le projet de démarrage, le débogage a recommencé.

Espérons que cela aide quelqu'un.

0

Évaluation:

Dans .NET «la fonction d'évaluation (funceval) » est la capacité du CLR à injecter un peu arbitraire appel alors que le debuggee est arrêté quelque part. Funceval prend en charge le thread choisi par le débogueur pour exécuter la méthode demandée. Une fois que funceval a fini, il déclenche un événement de débogage. Techniquement, CLR a défini des moyens pour que le débogueur émette un code funceval. CLR permet d'initier le funceval uniquement sur les threads qui sont au point GC safe (c'est-à-dire quand le thread ne bloque pas GC) et au point Funceval Safe (FESafe) (où CLR peut réellement faire le détournement du funceval). ensemble. Ainsi, les scénarios possibles pour CLR, un fil doit être:

  1. arrêté en code managé (et à un point sûr GC): Cela implique que nous ne pouvons pas faire un funceval en code natif. Depuis, le code natif est hors du contrôle du CLR, il est incapable de configurer le funceval.

  2. arrêté à une exception gérée de première chance ou non gérée (et à un point de sécurité GC): c'est-à-dire, au moment de l'exception, d'inspecter autant que possible pour déterminer pourquoi cette exception s'est produite. (Par exemple: débogueur peut essayer d'évaluer et de voir la propriété du message en cas d'exception soulevée.)

Dans l'ensemble, les moyens communs pour arrêter dans le code managé comprennent l'arrêt à un point d'arrêt, étape, appel Debugger.Break, intercepter une exception ou au début d'un thread. Cela aide à évaluer la méthode et les expressions. Selon l'évaluation, si le thread n'est pas à un point FESafe et GCSafe, CLR ne pourra pas détourner le thread pour déclencher le funceval.En général, à la suite permet de se assurer funceval se déclenche lorsque prévu:

Étape # 1:

Assurez-vous que vous n'êtes pas essayer de déboguer un « Release » build. Release est entièrement optimisé et conduira ainsi à l'erreur dans la discussion. En utilisant la barre d'outils Standard ou le Gestionnaire de configuration, vous pouvez basculer entre Déboguer & Release.

Étape # 2:

Si vous obtenez toujours l'erreur, l'option de débogage peut être définie pour l'optimisation. Vérifiez & décochez la case « Optimiser le code » propriété sous projet « Propriétés »:

clic droit sur le projet Sélectionnez l'option « Propriétés » Aller à l'onglet « Build » Décochez la case à cocher « Optimiser le code »

Étape # 3:

Si l'erreur persiste, le mode Info de débogage est peut-être incorrect. définir Vérifier & à « complet » sous « Avancé paramètres de construction »:

clic droit sur le projet Sélectionnez l'option « Propriétés » Allez à l'onglet « Build » Cliquez sur le bouton « Avancé » Set « Info Debug » comme « complète »

Étape # 4:

Si vous faites face à toujours le problème, essayez ce qui suit:

Faites un « Clean » & alors un « Reconstruire » de votre solution f ile Pendant le débogage: Allez dans la fenêtre des modules (VS Menu -> Déboguer -> Windows -> Modules) Trouvez votre assembly dans la liste des modules chargés. Vérifiez le chemin indiqué contre l'ensemble chargé est ce que vous attendez qu'il soit Vérifiez la Timestamp modification du fichier pour confirmer que l'assemblée a été effectivement reconstruit Vérifiez si oui ou non le module chargé est optimisé ou non

Conclusion:

Ce n'est pas une erreur, mais une information basée sur certains paramètres et conçue selon le fonctionnement de .NET Runtime.

0

dans mon cas j'étais dans les mode de libération je l'ai changé pour déboguer tout a parfaitement fonctionné

5

Le dessous travaillé pour moi, merci @Vin.

J'ai rencontré ce problème lors de l'utilisation de VS 2015. Ma solution: la configuration a été sélectionnée (débogage). J'ai résolu cela en décochant la propriété Optimize Code sous les propriétés du projet.

Project (clic droit) => Propriétés => Construction (onglet) => décocher Optimize le code

2

Assurez-vous de ne pas quelque chose comme ça

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)] 

dans votre AssemblyInfo

0

J'ai eu un problème similaire et il a été résolu lorsque j'ai créé la solution en mode débogage et remplacé le fichier pdb dans le chemin d'exécution.

Questions connexes