mon service C # a une erreur d'exécution interne .NET qui pointe vers une émission de récursivité (par exemple le débordement de la pile). Le problème est que le service est assez grand, alors j'ai du mal à trouver où se produit la récursivité.
Quelqu'un peut-il accomplir avec une grande regex Mojo avec une chaîne de recherche qui trouverait ce dont j'ai besoin?
8 Réponses :
Une récursion n'est pas facile à trouver dans certaines situations telles que: donc une regex ne vous aiderait probablement pas à le trouver à moins que ce soit un cas trivial.
Ouais. Construisez un graphique d'appel et recherchez des cycles.
Et espérons qu'il n'y a pas de rappels OS impliqués dans la récursion;)
Que diriez-vous d'utiliser un outil de profilage comme RedGate's Fourts Profiler ou DotTrace ?
Ils offrent tous les deux des essais gratuits. Il suffit d'exécuter le code avec le profileur en cours d'exécution et il vous montrera rapidement où votre temps / mémoire est dépensé.
Je parierais que votre fonction récursive de problèmes collera un peu.
En outre, quel cadre de journalisation d'erreur utilisez-vous? En cas de réponse, envisagez d'en adopter un. Cette question concerne Les options. avec un bon système, vous devriez pouvoir obtenir la trace de la pile qui, si vous avez de la chance, peut vous donner des indices sur l'endroit où l'exception se produit.
J'ai des centaines d'installations autour de nous, c'est la seule instance qui me donne des convulsions. Je ne peux pas reproduire le problème, mais je voudrais au moins se rapprocher de lui, en localisant la récursion
Ceci est une question sans réponse dans le cas général. À l'exception des exemples les plus triviaux (par exemple, une fonction s'appelant directement), il n'ya aucun moyen d'analyser un programme et de déterminer si la récursivité se produit. Vous aurez juste besoin de commencer à frapper le débogueur ou d'autres outils d'exécution.
Ceci est un exemple de Halte Problème .
Oui tres vrai. Les services de débogage sont plus difficiles que les applications normales, ce qui peut être pourquoi ils demandent.
Je pense que vous sucez-le un peu. Dans la plupart des cas, je pense qu'une analyse statique a trouvé certains cycles - ce ne serait pas si difficile. Serait-ce exhaustif? Non, mais je pense faire une vérification pratique pour cela ne serait pas si difficile. L'utilisation d'une regex ne va pas arriver cependant.
Je pense que "certains cycles" convient aux "exemples les plus triviaux" que j'essayais de traverser. Mais oui, même si vous auriez probablement besoin d'un analyseur complet pour commencer.
Je suis d'accord sur un regexp ne va pas le couper ici.
Une manière plus directe serait d'obtenir un fichier de vidage et de le regarder pour voir où l'exception a été lancée.
ou vous pouvez regarder un outil d'analyse statique comme Ndepend pour examiner le flux de programmes.
Le moyen le plus simple de le faire est d'obtenir une trace de pile de la chose qui se bloque. La trace de la pile ressemblera à ceci: Le "FROB" est la fonction récursive. : -)
Je ne vous encourage pas à dépenser de l'argent sur les outils commerciaux, mais vous pouvez simplement vérifier le manuel ci-dessous pour voir comment ils le font généralement, quels facteurs sont pris en compte, etc.
dans dotnet 5 Votre application vous dira dans la sortie STDERR après qu'il s'est écrasé lorsque la récursivité s'est produite.
Stack overflow. Repeat 32128 times: -------------------------------- at SoExceptional.Program.RecursiveDeath() -------------------------------- at SoExceptional.Program.Main(System.String[]) Process finished with exit code -1,073,741,571.
Non, la seule raison pour laquelle je sache même que l'application s'est écrasée, c'est qu'il existe une entrée dans le journal des événements annonçant qu'une erreur interne .NETR Framework s'est produite et donne au code, que j'ai tracé pour empiler des problèmes de débordement.
Avez-vous déjà trouvé ce problème? Si c'est le cas, comment? Je pense que la plupart des gens ici n'ont pas compris que le programme se bloque sans enregistrer, sauf une erreur de débordement générale de pile dans le journal des événements de service.