Qu'est-ce que & # 8220; Impossible d'évaluer une expression, car le code de la méthode actuelle est optimisé. & # 8221; signifier?

https://stackoverflow.com/questions/131628

02-07-2019
|

Question

J'ai écrit du code avec beaucoup de récursivité, ce qui prend un peu de temps. À chaque fois que je "fais une pause" la course à regarder ce qui se passe, je reçois:

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

Je pense comprendre ce que cela signifie. Cependant, ce qui me laisse perplexe, c’est qu’après avoir frappé step, le code n’est plus "optimisé". plus, et je peux regarder mes variables. Comment cela peut-il arriver? Comment le code peut-il basculer entre code optimisé et non optimisé?

La solution

Le débogueur utilise FuncEval pour vous permettre de "consulter" " variables. FuncEval exige que les threads soient arrêtés dans du code géré à un point sécurisé GarbageCollector. Manuellement & pause; pause " l'exécution dans l'EDI provoque l'arrêt de tous les threads le plus tôt possible. Votre code hautement récursif aura tendance à s'arrêter à un point dangereux. Par conséquent, le débogueur n’est pas en mesure d’évaluer les expressions.

Appuyez sur F10 pour passer au prochain point de sécurité Funceval et activer l’évaluation des fonctions.

Pour plus d'informations, consultez les règles de FuncEval .

Autres conseils

Tant que la ligne Debug.Break () se trouve en haut de la pile d'appels, vous ne pouvez pas évaluer d'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.

Vous essayez probablement de déboguer votre application en mode publication 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 supprimées dès qu’elles ne sont plus utilisées dans la fonction. C’est pourquoi vous recevez ce message. En mode débogage avec les optimisations désactivées, vous ne devriez pas avoir cette erreur.

Cela m'a rendu fou. J'ai essayé de joindre avec du code géré et natif - pas question.

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

Accédez au projet / propriétés
Sélectionnez l'onglet Construire et cliquez sur Avancé ...
Assurez-vous que les informations de débogage sont définies sur " complet " (pas uniquement pdb)
Déboguez votre projet - le tour est joué!

Ce qui précède a fonctionné pour moi, merci @Vin.

J'avais ce problème lorsque j'utilisais VS 2015. Ma solution: la configuration a (Debug) sélectionné. J'ai résolu ce problème en décochant la propriété Optimize Code sous les propriétés du projet.

Projet (clic droit) = > Propriétés = > Construire (onglet) = > décochez Optimiser le code

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

Assurez-vous de ne pas avoir quelque chose comme ça

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

dans votre AssemblyInfo

L'ami d'un ami de Microsoft a envoyé ceci: http://blogs.msdn.com/rmbyers/archive/2008/08/16/Func_2D00_eval-can-fail-while-stopped-in -a-non_2D00_ méthode optimisée-gérée-qui-pousse-plus-que-256-arguments-octets-.aspx

Le problème le plus probable est que votre pile d'appels est optimisée car la signature de votre méthode est trop grande.

Vous avez eu le même problème, mais vous avez pu le résoudre en désactivant le recouvrement des exceptions dans le débogueur. Cliquez sur [Déboguer] [Exceptions] et définissez les exceptions sur "Non géré par l'utilisateur".

Normalement, je l’ai désactivée, mais elle est parfois utile. Je dois juste me rappeler de l'éteindre quand j'ai fini.

J'avais ce problème lorsque j'utilisais VS 2010. Ma configuration de solution a (Debug) sélectionné. J'ai résolu ce problème en décochant la propriété Optimiser le code sous Propriétés du projet. Projet (clic droit) = > Propriétés = > Construire (onglet) = > décochez Optimiser le code

Dans mon cas, j'avais 2 projets dans ma solution et je dirigeais un projet autre que le projet de démarrage. Lorsque je l'ai changé en projet de démarrage, le débogage a recommencé à fonctionner.

J'espère que cela aidera quelqu'un.

Évaluation:

Dans .NET, «Evaluation de la fonction (funceval)» est la capacité du CLR d’injecter un appel arbitraire pendant que le débogage 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 terminé, il déclenche un événement de débogage. Techniquement, les CLR ont défini des méthodes permettant au débogueur d’émettre un funceval.

CLR permet d’initialiser funceval uniquement sur les threads situés au point de sécurité GC (c’est-à-dire lorsque le thread ne bloque pas le GC) et le point Funceval Safe (FESafe) (c’est-à-dire où CLR peut réellement effectuer le détournement du funceval.) . Ainsi, scénarios possibles pour CLR, un thread doit être:

arrêté en code managé (et à un point sécurisé du GC): cela implique que nous ne pouvons pas créer de fonction en code natif. Le code natif étant en dehors du contrôle du CLR, il est impossible de configurer le funceval.
s’est arrêté à la 1ère chance ou à une exception gérée non gérée (et à un point sûr du GC): c’est-à-dire qu’au moment de l’exception, inspectez autant que possible pour déterminer la raison de cette exception. (par exemple: le débogueur peut essayer d’évaluer et de voir la propriété Message lors d’une exception levée.)

Dans l’ensemble, les méthodes courantes d’arrêt dans le code managé incluent l’arrêt à un point d'arrêt, une étape, un appel Debugger.Break, l'interception d'une exception ou le démarrage d'un thread. Cela aide à évaluer la méthode et les expressions.

Résolutions possibles: Sur la base de l'évaluation, si le thread ne se trouve pas aux points FESafe et GCSafe, le CLR ne pourra pas le détourner pour lancer funceval. En règle générale, la procédure suivante permet de s’assurer que funceval s’initie au moment prévu:

Étape n ° 1:

Assurez-vous que vous n'essayez pas de déboguer une version «Release». La publication est entièrement optimisée et entraînera donc une erreur de discussion. À l'aide de la barre d'outils Standard ou du Gestionnaire de configuration, vous pouvez basculer entre Debug et amp; Libérer.

Étape n ° 2:

Si vous obtenez toujours l'erreur, l'option de débogage peut être définie pour l'optimisation. Vérifiez & amp; Décochez la propriété "Optimiser le code" sous Projet "Propriétés":

Faites un clic droit sur le projet Sélectionnez l'option "Propriétés" Aller à l'onglet "Construire" Décochez la case "Optimiser le code"

Étape 3:

Si l'erreur persiste, le mode informations de débogage est peut-être incorrect. Vérifiez & amp; réglez-le sur «complet» sous «Paramètres de construction avancés»:

Faites un clic droit sur le projet Sélectionnez l'option "Propriétés" Aller à l'onglet "Construire" Cliquez sur le bouton "Avancé" Définissez «Informations de débogage» sur «Complet»

Étape 4:

Si le problème persiste, essayez les solutions suivantes:

Faites un "nettoyage" & amp; puis une «reconstruction» de votre fichier de solution Pendant le débogage: Accéder à la fenêtre des modules (Menu VS - > Débogage - > Windows - > Modules) Trouvez votre assemblage dans la liste des modules chargés. Vérifiez que le chemin indiqué par rapport à l'assembly chargé correspond à ce que vous attendez de lui. Vérifiez l'horodatage modifié du fichier pour confirmer que l'assembly a bien été reconstruit. Vérifiez si le module chargé est optimisé ou non

Conclusion:

Il ne s’agit pas d’une erreur mais d’une information basée sur certains paramètres et conçue selon le fonctionnement de l’exécution .NET.

dans mon cas, j’étais en mode de publication, j’ai changé pour tout mettre au point

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.

Je pense que ce que vous constatez résulte des optimisations. Parfois, une variable sera réutilisée, en particulier celles créées sur la pile. Par exemple, supposons que votre méthode utilise deux entiers (locaux). Le premier entier est déclaré au début de la méthode et sert uniquement de compteur pour une boucle. Votre second entier est utilisé une fois la boucle terminée et stocke le résultat d'un calcul qui est ensuite écrit dans un 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 deuxième entier plus tôt, vous obtenez le message que vous demandez à 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 ultérieurement la valeur du deuxième entier dans un élément de pile séparé, ce qui vous permet d’accéder ensuite à la valeur à partir du débogueur.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow