C# StackOverFlowException

[Fallen]

Bonjour,
J'ai une question que je me pose sur l'exception StackOverFlow,
est ce qu'il y a un moyen de gérer cette exception sans devoir repasser au Framework .Net 1 ?
J'ai vu quelque exemple pour la gérer mais c'est assez farfelu.
Si quelqu'un a des idées, J'en serais heureux de les entendre et je pense que je ne suis pas le seul ^^

 

[BlueDream]

est ce qu'il y a un moyen de gérer cette exception sans devoir repasser au Framework .Net 1 ?

En quoi repasser au framework 1 te fera "gérer" l'exception ?
Quand tu as une exception tu cherches simplement à la résoudre, je pense que c'est ton code le problème et surement pas le framework.

 

[Kyu]

En générale cette exception est lancée quand tu fais une boucle infinie par récursivité.

Par exemple : La méthode A appelle la méthode B et la méthode B appelle la méthode A.
La seul solution pour gérer cette exception est de corriger le problème dans ton code.

 

[DrBrook]

Donne nous le code qui te provoque cette exception...

 

[Arth]

La détection d'un stackoverflow c'est une exception inquiétante, il ne faut pas chercher à la gère, il faut à tout prix corriger le code. De toute façon c'est une exception qui est détecté quand tu as écrasé des données utiliser par d'autres bout de code alors c'est utopique de la "gérer".

 

[Fallen]

En quoi repasser au framework 1 te fera "gérer" l'exception ?
Quand tu as une exception tu cherches simplement à la résoudre, je pense que c'est ton code le problème et surement pas le framework.

En générale cette exception est lancée quand tu fais une boucle infinie par récursivité.

Par exemple : La méthode A appelle la méthode B et la méthode B appelle la méthode A.
La seul solution pour gérer cette exception est de corriger le problème dans ton code.

Donne nous le code qui te provoque cette exception...

Je n'ai aucun code c'était plus une question comme ça mais j'ai vu que parfois le framework pouvais généré un stackoverflow par lui même à cause d'un code en interne comme ici
http://stackoverflow.com/questions/206820/how-do-i-prevent-and-or-handle-a-stackoverflowexception

La détection d'un stackoverflow c'est une exception inquiétante, il ne faut pas chercher à la gère, il faut à tout prix corriger le code. De toute façon c'est une exception qui est détecté quand tu as écrasé des données utiliser par d'autres bout de code alors c'est utopique de la "gérer".

Si vous regardez dans le MSDN il est bien marqué que le Frmaework 1 pouvais la gérer comme une exception à part entière grace au block try catch

 

[BlueDream]

C'est assez étrange de vouloir fix une exception que tu ne rencontres même pas... Personnellement je n'ai jamais eu ce genre de problème

 

[Fallen]

C'est assez étrange de vouloir fix une exception que tu ne rencontres même pas... Personnellement je n'ai jamais eu ce genre de problème

D'un autre coté, quand tu as une exception StackOverFlow tu n'a pas de StackTrace donc chaud d'aller trouver d'ou vient le problème si tu as 1000 boucles récursives x) je trouve ça bête de la part de Microsoft de ne plus gérer le StackOverFlow grace au try catch, par exemple sur un émulateur ça va vite de tomber sur un StackOverFlow x)

 

[DrBrook]

Ca va vite si tu fais mal les choses. Sinon, aucun soucis.

 

[Arth]

Pour les raisons qui font apparaître un stack overflow :
- il y a les fonctions récursives (et compilé comme récursive) qui ont trop d’itération et c'est juste le code qui est mal construit ou mal compilé.
- mais il peut aussi avoir des erreurs de gestion de buffer static dans une fonction.

Pour moi il est hors de question de continuer l’exécution d'un code après un stack overflow.

Ce genre de problème à été, pour un temps, la porte ouverte la plus violente qu'on puisse trouver dans un programme. SI on peut en produire un, on peut modifier le contenu du stack à volonté, dans le stack il y a les adresses de retour de fonction... Cela veut dire que l'on peut exécuter le code que l'on veut dans le programme, il était courant d'utiliser les adresses de retour pour exécuter un bout de code que l'attaquant aura écrit lui même dans le stack. C'est à dire que cela permet a l'attaquant d'injecter du code et de l’exécuter... Je te laisse imaginer les dégât. Même si c'est problème la ne sont plus d’actualité, les erreurs dans le stack reste critique.

Si Microsoft prévoit de gérer ce genre de problème c'est sûrement pour pouvoir sauvegarder un document avant de quitter. Je ne sais pas si c'est une bonne idée.

 

[Fallen]

Pour les raisons qui font apparaître un stack overflow :
- il y a les fonctions récursives (et compilé comme récursive) qui ont trop d’itération et c'est juste le code qui est mal construit ou mal compilé.
- mais il peut aussi avoir des erreurs de gestion de buffer static dans une fonction.

Pour moi il est hors de question de continuer l’exécution d'un code après un stack overflow.

Ce genre de problème à été, pour un temps, la porte ouverte la plus violente qu'on puisse trouver dans un programme. SI on peut en produire un, on peut modifier le contenu du stack à volonté, dans le stack il y a les adresses de retour de fonction... Cela veut dire que l'on peut exécuter le code que l'on veut dans le programme, il était courant d'utiliser les adresses de retour pour exécuter un bout de code que l'attaquant aura écrit lui même dans le stack. C'est à dire que cela permet a l'attaquant d'injecter du code et de l’exécuter... Je te laisse imaginer les dégât. Même si c'est problème la ne sont plus d’actualité, les erreurs dans le stack reste critique.

Si Microsoft prévoit de gérer ce genre de problème c'est sûrement pour pouvoir sauvegarder un document avant de quitter. Je ne sais pas si c'est une bonne idée.

Comment voir d'ou vient le problème souvent tu as des centaines de boucles récursive dans un émulateur...
Je comprends que continuer un programme après un stackoverflow et pas la meilleur idée mais au mois savoir d'ou vient le problème.

Ca va vite si tu fais mal les choses. Sinon, aucun soucis.

L'humain est loin d'être à l'abri d'un erreur ^^


Après tout ceci c'est juste une question de culture général, je suis loin d'avoir le problème

 

[Arth]

Quand tu écrit un bout de code récursif, les bons compilateurs sont capable de compiler ce code comme un bout de code itératif. (tail-call optimization)
Mais cela dépend du code à compilé et du compilateur.
SI ton code récursif et suffisamment simple et ton compilateur pas trop mal fait, tu n'aura aucun problème même avec des quantité d’itération très haute.

Si malgré cela tu rencontre un problème, tu as plusieurs choix :
- le choix stupide (ou pas suivant le cas) : dire au compilateur de donner une pile plus grande au programme.
- Optimiser pour que les frames des fonctions sois plus petite dans la stack. (c'est le choix hardcore et incertain mdr)
- ré-ecrire le bout de code incriminé en iltratif ou en réduisant le nombre d’itération. C'est le choix de l'optimisation.

Pour le détecter... ça dépend des cas ^^

 

[Fallen]

Quand tu écrit un bout de code récursif, les bons compilateurs sont capable de compiler ce code comme un bout de code itératif. (tail-call optimization)
Mais cela dépend du code à compilé et du compilateur.
SI ton code récursif et suffisamment simple et ton compilateur pas trop mal fait, tu n'aura aucun problème même avec des quantité d’itération très haute.

Si malgré cela tu rencontre un problème, tu as plusieurs choix :
- le choix stupide (ou pas suivant le cas) : dire au compilateur de donner une pile plus grande au programme.
- Optimiser pour que les frames des fonctions sois plus petite dans la stack. (c'est le choix hardcore et incertain mdr)
- ré-ecrire le bout de code incriminé en iltratif ou en réduisant le nombre d’itération. C'est le choix de l'optimisation.

Pour le détecter... ça dépend des cas ^^

Ok donc impossible d'avoir un apercu du stacktrace après l'erreur ?

 

[Arth]

Si c'est à la suite d'un appel récursif je ne voit pas quel partie du stack est détruite, c'est plutôt le stack qui écrase le heap normalement dans ce cas. donc en théorie tu peut voir tes frames. Mais je suis plutôt C/C++, donc je ne peux pas te dire pour ton framework.

Si c'est dut à un buffer mal gérer tu écrase des frames. Donc ça risque d’être complexe.
Faut voir sur ton debugger =)

 

[Fallen]

Ok je code en C/C++ mais seulement quand j'ai pas la flemme xD
mais merci des explications ^^

 

[Taykyue]

Et avec l'event UnhandledException, tu ne peux pas réussir à comprendre l'erreur ?

https://msdn.microsoft.com/fr-fr/library/system.appdomain.unhandledexception(v=vs.110).aspx

 

[Apokah]

Normalement une exception non géré passe par UnhandledException comme a dit Taykyue, donc de là tu peux trace d'où vient l'erreur ^^

 

[Fallen]

Normalement une exception non géré passe par UnhandledException comme a dit Taykyue, donc de là tu peux trace d'où vient l'erreur ^^

Et avec l'event UnhandledException, tu ne peux pas réussir à comprendre l'erreur ?

https://msdn.microsoft.com/fr-fr/library/system.appdomain.unhandledexception(v=vs.110).aspx

oui Effectivement mais en me baladant un peu sur le net je suis tombé sur ça aussi
http://www.abhisheksur.com/2011/01/internals-of-exception-handling.html