> Voilà ce que j'ai fait, mais il me fait toujour sl'erreur!! :{{
On ne peut pas répondre à ta question sans avoir un code complet. On ne veut pas répondre à ta question avec un code qui contient plein de trucs qui n'ont rien à voir avec le probleme. Donc je réitere ma proposition : si tu postes un code qui compile, qui peut être lancé, qui présente le problème et qui ne contienne rien de superflu (ou pas trop de trucs superflus), je suis prêt à t'aider.
-- Vincent
> Voilà ce que j'ai fait, mais il me fait toujour sl'erreur!! :{{
On ne peut pas répondre à ta question sans avoir un code complet.
On ne veut pas répondre à ta question avec un code qui contient plein de
trucs qui n'ont rien à voir avec le probleme.
Donc je réitere ma proposition : si tu postes un code qui compile, qui peut
être lancé, qui présente le problème et qui ne contienne rien de superflu
(ou pas trop de trucs superflus), je suis prêt à t'aider.
> Voilà ce que j'ai fait, mais il me fait toujour sl'erreur!! :{{
On ne peut pas répondre à ta question sans avoir un code complet. On ne veut pas répondre à ta question avec un code qui contient plein de trucs qui n'ont rien à voir avec le probleme. Donc je réitere ma proposition : si tu postes un code qui compile, qui peut être lancé, qui présente le problème et qui ne contienne rien de superflu (ou pas trop de trucs superflus), je suis prêt à t'aider.
Namespace:System.Diagnostics.Debug Assembly: System.dll -- Paul Bacelar
"amplitude" wrote in message news:cl7tbg$8oe$ Merci bcp pour toutes ces explications, je comprend mieux! :)
Sinon, quel est l'assembly de Debug, pcq qu'il ne le trouve pas, et moi non plus...
Paul Bacelar wrote:
Bon, on commence par le début ;-).
StackOverFlow, c'est un dépassement de capacité de la pile.
La pile c'est la zone mémoire qui est utilisé pour stocker les variables automatiques.
Les variables automatiques, c'est les variables que le langages alloue automatiquement comme les arguments du méthode que tu passe par valeur ou les variables locale de type ValueType (in, float, double, struct, etc.). Ces variables sont à l'opposé des variables allouées avec un new qui elle sont stockées dans le tas (heap). Le garbage collector ne s'occupe que du tas.
La gestion de variables automatiques se fait par empilement-dépilement. Quand tu entres dans une méthode, la pile augmente de la taille de tes variables automatiques (paramètres et variables locales). Quand tu sors de la méthode, la pile diminue d'autan qu'elle a augmenté en entrant.
Donc entre l'entrée dans une méthode et sa sortie, la pile a augmenté en taille. Mais la taille de la pile au moment de la sortie est la même qu'à son entré dans la méthode.
C'est pareil pour tous les langages, .NET ou pas.
Alors comment une pile peut-elle grandir jusqu'à exploser l'espace qui lui était réservé ?
J'en vois deux:
- une récursivité trop profonde, c'est à dire une méthode qui s'appel elle même de manière direct ou indirect, ce qui entraîne une augmentation de la pile à chaque appel qui entraînera un nouvel appel avec une nouvelle augmentation de la pile et ainsi de suite jusqu'au dénouement fatale.
- une taille de l'ensemble des variables automatiques très importantes, comme une structure contenant des millions de int passé par valeur à plusieurs méthodes successivement. Cette hypothèse est peu plausible avec les langages .NET qui utilisent énormément les références sur des objets contrairement au C avec ses tableaux.
Tout cela ne sont que des généralités mais il faut bien être conscient de
la
situation, qui est pour le moins critique et hostile.
Si mes lieux communs ont été suffisamment clairs, le fait d'appeler une méthode comme MessageBox qui utilise des variables automatiques (au moins pour ses paramètres) quand une StackOverFlow est lancée sera aussi
saugrenue
que de faire un new pendant le traitement d'une exception de type OutOfMemory ;-).
Si l'image te frappe, tu comprendra que tu ne verra pas de MessageBox car
tu
as subis une StackOverFlowException pendant le traitement de la première exception (c'est un throw dans un catch).
Il ne reste donc qu'a rusé pour voir le problème avant que la pile soit pleine car après, c'est Tchernobyl dans la mémoire, même le débuggeur y
perd
ses petits car le contenue de la stack a de fortes chances d'être
corrompu.
Alors, petit padawan, depuis des temps qui datent de bien avant
l'existence
des premiers débuggeurs, de vaillants programmeurs, seulement munis de
leur
simples bibliothèques d'entrée-sortie (et même pas laser), ont mis au
point
une technique ultra puissante.
C'est simplement d'afficher sur la console des traces de l'activité du programme.
Le printf("coucou") de mon précédent post est une instruction C qui ne
fait
qu'afficher "coucou" dans la console du programme à la suite des autres affichages. Si dans la console a affiché un "coucou", c'est que nous
sommes
passée une fois dans cette instruction, si il y a 2 "coucou", c'est que
nous
sommes passée deux fois dans cette instruction etc...
Avec .NET, les bibliothèques d'entrées-sorties se sont perfectionnées et "Debug.Write("coucou")" est l'instruction .NET qui va permettre d'afficher "coucou" dans la fenêtre "Sortie" ou "Output" de VS.NET, la fenêtre qui
est
généralement en bas et qui indique le chargement des assemblies.
dans ta boucle permettra de voir l'évolutions de ces valeurs avant que le drame (l'explosion de la pile) n'arrive.
PS: Voici un exemple du pourquoi il ne faut pas catcher les exceptions
quand
on n'est pas capable des les résoudre.
Ne catchez pas à tord et à travers ;-). En catchant Exception, vous pouvez avoir une OutOfMemoryException et si vous avez pas réservé de la mémoire pour un traitement d'urgence, vous aurez l'air fin avec votre catch.
Namespace:System.Diagnostics.Debug
Assembly: System.dll
--
Paul Bacelar
"amplitude" <news@ampBLOUdesign.net> wrote in message
news:cl7tbg$8oe$1@apollon.grec.isp.9tel.net...
Merci bcp pour toutes ces explications, je comprend mieux! :)
Sinon, quel est l'assembly de Debug, pcq qu'il ne le trouve pas, et moi
non plus...
Paul Bacelar wrote:
Bon, on commence par le début ;-).
StackOverFlow, c'est un dépassement de capacité de la pile.
La pile c'est la zone mémoire qui est utilisé pour stocker les variables
automatiques.
Les variables automatiques, c'est les variables que le langages alloue
automatiquement comme les arguments du méthode que tu passe par valeur ou
les variables locale de type ValueType (in, float, double, struct, etc.).
Ces variables sont à l'opposé des variables allouées avec un new qui elle
sont stockées dans le tas (heap). Le garbage collector ne s'occupe que du
tas.
La gestion de variables automatiques se fait par empilement-dépilement.
Quand tu entres dans une méthode, la pile augmente de la taille de tes
variables automatiques (paramètres et variables locales). Quand tu sors de
la méthode, la pile diminue d'autan qu'elle a augmenté en entrant.
Donc entre l'entrée dans une méthode et sa sortie, la pile a augmenté en
taille. Mais la taille de la pile au moment de la sortie est la même qu'à
son entré dans la méthode.
C'est pareil pour tous les langages, .NET ou pas.
Alors comment une pile peut-elle grandir jusqu'à exploser l'espace qui lui
était réservé ?
J'en vois deux:
- une récursivité trop profonde, c'est à dire une méthode qui s'appel elle
même de manière direct ou indirect, ce qui entraîne une augmentation de la
pile à chaque appel qui entraînera un nouvel appel avec une nouvelle
augmentation de la pile et ainsi de suite jusqu'au dénouement fatale.
- une taille de l'ensemble des variables automatiques très importantes,
comme une structure contenant des millions de int passé par valeur à
plusieurs méthodes successivement. Cette hypothèse est peu plausible avec
les langages .NET qui utilisent énormément les références sur des objets
contrairement au C avec ses tableaux.
Tout cela ne sont que des généralités mais il faut bien être conscient de
la
situation, qui est pour le moins critique et hostile.
Si mes lieux communs ont été suffisamment clairs, le fait d'appeler une
méthode comme MessageBox qui utilise des variables automatiques (au moins
pour ses paramètres) quand une StackOverFlow est lancée sera aussi
saugrenue
que de faire un new pendant le traitement d'une exception de type
OutOfMemory ;-).
Si l'image te frappe, tu comprendra que tu ne verra pas de MessageBox car
tu
as subis une StackOverFlowException pendant le traitement de la première
exception (c'est un throw dans un catch).
Il ne reste donc qu'a rusé pour voir le problème avant que la pile soit
pleine car après, c'est Tchernobyl dans la mémoire, même le débuggeur y
perd
ses petits car le contenue de la stack a de fortes chances d'être
corrompu.
Alors, petit padawan, depuis des temps qui datent de bien avant
l'existence
des premiers débuggeurs, de vaillants programmeurs, seulement munis de
leur
simples bibliothèques d'entrée-sortie (et même pas laser), ont mis au
point
une technique ultra puissante.
C'est simplement d'afficher sur la console des traces de l'activité du
programme.
Le printf("coucou") de mon précédent post est une instruction C qui ne
fait
qu'afficher "coucou" dans la console du programme à la suite des autres
affichages. Si dans la console a affiché un "coucou", c'est que nous
sommes
passée une fois dans cette instruction, si il y a 2 "coucou", c'est que
nous
sommes passée deux fois dans cette instruction etc...
Avec .NET, les bibliothèques d'entrées-sorties se sont perfectionnées et
"Debug.Write("coucou")" est l'instruction .NET qui va permettre d'afficher
"coucou" dans la fenêtre "Sortie" ou "Output" de VS.NET, la fenêtre qui
est
généralement en bas et qui indique le chargement des assemblies.
dans ta boucle permettra de voir l'évolutions de ces valeurs avant que le
drame (l'explosion de la pile) n'arrive.
PS: Voici un exemple du pourquoi il ne faut pas catcher les exceptions
quand
on n'est pas capable des les résoudre.
Ne catchez pas à tord et à travers ;-). En catchant Exception, vous pouvez
avoir une OutOfMemoryException et si vous avez pas réservé de la mémoire
pour un traitement d'urgence, vous aurez l'air fin avec votre catch.
Namespace:System.Diagnostics.Debug Assembly: System.dll -- Paul Bacelar
"amplitude" wrote in message news:cl7tbg$8oe$ Merci bcp pour toutes ces explications, je comprend mieux! :)
Sinon, quel est l'assembly de Debug, pcq qu'il ne le trouve pas, et moi non plus...
Paul Bacelar wrote:
Bon, on commence par le début ;-).
StackOverFlow, c'est un dépassement de capacité de la pile.
La pile c'est la zone mémoire qui est utilisé pour stocker les variables automatiques.
Les variables automatiques, c'est les variables que le langages alloue automatiquement comme les arguments du méthode que tu passe par valeur ou les variables locale de type ValueType (in, float, double, struct, etc.). Ces variables sont à l'opposé des variables allouées avec un new qui elle sont stockées dans le tas (heap). Le garbage collector ne s'occupe que du tas.
La gestion de variables automatiques se fait par empilement-dépilement. Quand tu entres dans une méthode, la pile augmente de la taille de tes variables automatiques (paramètres et variables locales). Quand tu sors de la méthode, la pile diminue d'autan qu'elle a augmenté en entrant.
Donc entre l'entrée dans une méthode et sa sortie, la pile a augmenté en taille. Mais la taille de la pile au moment de la sortie est la même qu'à son entré dans la méthode.
C'est pareil pour tous les langages, .NET ou pas.
Alors comment une pile peut-elle grandir jusqu'à exploser l'espace qui lui était réservé ?
J'en vois deux:
- une récursivité trop profonde, c'est à dire une méthode qui s'appel elle même de manière direct ou indirect, ce qui entraîne une augmentation de la pile à chaque appel qui entraînera un nouvel appel avec une nouvelle augmentation de la pile et ainsi de suite jusqu'au dénouement fatale.
- une taille de l'ensemble des variables automatiques très importantes, comme une structure contenant des millions de int passé par valeur à plusieurs méthodes successivement. Cette hypothèse est peu plausible avec les langages .NET qui utilisent énormément les références sur des objets contrairement au C avec ses tableaux.
Tout cela ne sont que des généralités mais il faut bien être conscient de
la
situation, qui est pour le moins critique et hostile.
Si mes lieux communs ont été suffisamment clairs, le fait d'appeler une méthode comme MessageBox qui utilise des variables automatiques (au moins pour ses paramètres) quand une StackOverFlow est lancée sera aussi
saugrenue
que de faire un new pendant le traitement d'une exception de type OutOfMemory ;-).
Si l'image te frappe, tu comprendra que tu ne verra pas de MessageBox car
tu
as subis une StackOverFlowException pendant le traitement de la première exception (c'est un throw dans un catch).
Il ne reste donc qu'a rusé pour voir le problème avant que la pile soit pleine car après, c'est Tchernobyl dans la mémoire, même le débuggeur y
perd
ses petits car le contenue de la stack a de fortes chances d'être
corrompu.
Alors, petit padawan, depuis des temps qui datent de bien avant
l'existence
des premiers débuggeurs, de vaillants programmeurs, seulement munis de
leur
simples bibliothèques d'entrée-sortie (et même pas laser), ont mis au
point
une technique ultra puissante.
C'est simplement d'afficher sur la console des traces de l'activité du programme.
Le printf("coucou") de mon précédent post est une instruction C qui ne
fait
qu'afficher "coucou" dans la console du programme à la suite des autres affichages. Si dans la console a affiché un "coucou", c'est que nous
sommes
passée une fois dans cette instruction, si il y a 2 "coucou", c'est que
nous
sommes passée deux fois dans cette instruction etc...
Avec .NET, les bibliothèques d'entrées-sorties se sont perfectionnées et "Debug.Write("coucou")" est l'instruction .NET qui va permettre d'afficher "coucou" dans la fenêtre "Sortie" ou "Output" de VS.NET, la fenêtre qui
est
généralement en bas et qui indique le chargement des assemblies.
dans ta boucle permettra de voir l'évolutions de ces valeurs avant que le drame (l'explosion de la pile) n'arrive.
PS: Voici un exemple du pourquoi il ne faut pas catcher les exceptions
quand
on n'est pas capable des les résoudre.
Ne catchez pas à tord et à travers ;-). En catchant Exception, vous pouvez avoir une OutOfMemoryException et si vous avez pas réservé de la mémoire pour un traitement d'urgence, vous aurez l'air fin avec votre catch.
