Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement ASP.Net systemoutofmemoryexception

systemoutofmemoryexception

4 réponses
Avatar
Eric
Bonjour à tous,

je developpe un site web (application) en asp.net (framework 2)
et chez certains de mes clients (ceux ou l'activité est plus intense),
l'erreur suivante : systemOutOfMemoryException revient regulierement ...
on tue le process asp.net et/ou redemarre IIS et ça repart mais bon ...
Dans mon code il y avait pas mal de try catch utilisés comme des if else
... serait-ce lié ?
sinon avez vous des pistes ?

merci pour infos,
Eric.
Signaler un problème avec ce contenu

4 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Gilles TOURREAU
Le Fri, 13 Apr 2007 11:47:10 +0200, Eric a écrit:

Bonjour à tous,

je developpe un site web (application) en asp.net (framework 2)
et chez certains de mes clients (ceux ou l'activité est plus intense),
l'erreur suivante : systemOutOfMemoryException revient regulierement ...
on tue le process asp.net et/ou redemarre IIS et ça repart mais bon ...
Dans mon code il y avait pas mal de try catch utilisés comme des if else
... serait-ce lié ?
sinon avez vous des pistes ?

merci pour infos,
Eric.





Pouvez vous poster une partie de vos try/catch ?

Cordialement

--
Gilles TOURREAU


S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Avatar
Damien Pinauldt
Bonjour,
Voila le genre d'erreur de programmation que l'on effectué :

Try

Donne_Numero_Commande = DR.GetValue(0)

Catch

Donne_Numero_Commande = ""

End Try


[...]
Et pendant que j'y suis j'abuse : y'a t-il un moyen d'eviter
'System.Threading.ThreadAbortException' à chaque fois que l'on change de
page ?




Je n'ai pas suivi toute la discution en détail, mais si "DR" est un
DataReader, il ne faut pas oublier de le fermer... Par exemple en
faisant un using(){} (je ne sais pas si on peut faire ça en VB, si non
il faut appeler le .Dispose()).

Dans mon équipe, nous avons créé tout un tas de méthodes utilitaires
pour factoriser les tests sur les DBNull.

Par exemple (en simplifié) :

public int? GetIntValue(IDataReader idr, int colNumber)
{
object o = idr.GetValue(colNumber);
return ( o is DBNull ? null : Convert.ToInt32(o));
}
Avatar
Gilles TOURREAU
Le Mon, 16 Apr 2007 17:26:37 +0200, Eric a écrit:

Voila le genre d'erreur de programmation que l'on effectué :
Try

Donne_Numero_Commande = DR.GetValue(0)

Catch

Donne_Numero_Commande = ""

End Try

au lieu de tester le dr.getvalue(0) is system.dbnull.value avec l'aide
d'un simple if else par exemple ...

Et donc une erreur de System.InvalidCastException (il me semble) etait
générée (en regardant dans l'onglet sortie en mode debug) ou toute autre
exception selon le cas.

J'ai (commencé) supprimé ces 'erreurs' mais est- ce la seule raison qui
fait qu'une autre erreur (OutOfMemory ) se produise au bout de quelques
temps (de plus à ce moment la dans le gestionnaire des taches aspNet
utilise enormement de mémoire , comme s'il n'arrivait plus à se réguler
..)

Voila ce que je peux préciser, désolé d'être 'un peu' confus ...

Et pendant que j'y suis j'abuse : y'a t-il un moyen d'eviter
'System.Threading.ThreadAbortException' à chaque fois que l'on change de
page ?



Merci d'avance,

Eric.



"Gilles TOURREAU" a écrit dans le message de
news:
Le Fri, 13 Apr 2007 11:47:10 +0200, Eric a écrit:

Bonjour à tous,

je developpe un site web (application) en asp.net (framework 2)
et chez certains de mes clients (ceux ou l'activité est plus intense),
l'erreur suivante : systemOutOfMemoryException revient regulierement
...
on tue le process asp.net et/ou redemarre IIS et ça repart mais bon ...
Dans mon code il y avait pas mal de try catch utilisés comme des if
else
... serait-ce lié ?
sinon avez vous des pistes ?

merci pour infos,
Eric.





Pouvez vous poster une partie de vos try/catch ?

Cordialement

--
Gilles TOURREAU


S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr





Eviter dans un premier temps d'utiliser les try/catch pour "tester une
valeur", cela consomme beaucoup de ressources CPU...
Les exceptions sont là uniquement pour être déclenché lors d'une erreur de
programmation...

Ce genre de code pour ouvrir un fichier par exemple est déconseillé :

Try
File.Open(...)
Catch
Message("Nom de fichier incorrect");
End Try

Il faut mieux écrire :

If File.Exists(...) = False Then
Message("Nom de fichier incorrect");
Else If VérifierDroitFichier(...) == False
Message("Vous n'avez pas le droit d'ouvrir le fichier...")
Else
Try
File.Open(...)
Catch
Message("Oups... Erreur de programmation... Le développeur a oublié
de vérifier quelque chose...");
End Try
End If

Utiliser donc toujours des If/Else... Dans la théorie absolue il devrait
jamais avoir de try/catch dans le code d'une application, mais juste un au
niveau "global" de l'application, afin de signaler à l'utilisateur qu'il y
a un bug (ou au niveau thread si on peut arrêter une partie de
l'application)...

Le second défaut de votre code, si vous faite un Try/Catch ou
Try/Catch(Exception) vous allez "choper" toutes les exceptions qui sont
déclenché ! Et donc aussi celle qui concerne les "erreurs brutes" de
codage tel que : ArgumentNullException (passage d'un paramètre null à une
méthode), NullReferenceException (Référence à une variable null) :

Si on applique votre code ainsi :

Try

Donne_Numero_Commande = DR.GetValue(0)

Catch

Donne_Numero_Commande = ""

End Try

Imaginons que DR = null, vous ne verrez pas cette erreur se déclencher (à
l'execution et au débogage !!!) et automatiquement le code du Catch sera
déclenché. En résumé vous avez traité une exception qui n'aurait pas du
l'être !
Donc spécialisez toujours vos exceptions par :

Try
...
Catch (FileNotFoundException)
...
Catch (FormatException)
...
End Try

Ainsi dans ce code, en cas de déclenchement de NullReferenceException,
tout saute et suffit de corriger !

Et le 3ème point concernant qui peut être du au OutOfMemoryException :
Utilisez la clause Finally afin de libérer les ressources "Disposable"
(implémentant la classe IDisposable) afin que celle-ci soit déclenché avec
ou sans exception...

OuvrirConnexion()

Try
Remplir(DataTable)
Catch
...
Finally
FermerConnexion();

Le mieux c'est d'utiliser la directive using ainsi :

Try
Using(OuvrirConnexion())
{
Remplir(DataTable)
}
Catch
...

L'OutOfMemoryException peut être du à cette non libération de ressources
correct...

Pour en finir, j'ai eu un collègue qui a eu ce genre de problème à cause
d'un traitement exception qui faisait tourner le programme à l'infini
(pendant 10 sec, et après OutOfMemoryException...) tout çà parceque il
avait fait un Try/Catch(Exception) qui englobait toutes les exceptions. Le
programme tournait donc constamment pendant 10 sec alors qu'il aurait du
planter depuis longtemps...

J'espère que je vous ai un peu éclairait...
Excusez moi encore de ma syntaxe au niveau du code, mais je suis
développeur C#...

Cordialement

--
Gilles TOURREAU


S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Avatar
Eric
Merci pour toutes vos précisions,
je comprends donc que les try catch sont très pratique mais a utiliser avec
parcimonie ...

Encore merci, à vous deux, bonne journée et à bientôt !
Eric.
"Gilles TOURREAU" a écrit dans le message de news:

Le Mon, 16 Apr 2007 17:26:37 +0200, Eric a écrit:

Voila le genre d'erreur de programmation que l'on effectué :
Try

Donne_Numero_Commande = DR.GetValue(0)

Catch

Donne_Numero_Commande = ""

End Try

au lieu de tester le dr.getvalue(0) is system.dbnull.value avec l'aide
d'un simple if else par exemple ...

Et donc une erreur de System.InvalidCastException (il me semble) etait
générée (en regardant dans l'onglet sortie en mode debug) ou toute autre
exception selon le cas.

J'ai (commencé) supprimé ces 'erreurs' mais est- ce la seule raison qui
fait qu'une autre erreur (OutOfMemory ) se produise au bout de quelques
temps (de plus à ce moment la dans le gestionnaire des taches aspNet
utilise enormement de mémoire , comme s'il n'arrivait plus à se réguler
..)

Voila ce que je peux préciser, désolé d'être 'un peu' confus ...

Et pendant que j'y suis j'abuse : y'a t-il un moyen d'eviter
'System.Threading.ThreadAbortException' à chaque fois que l'on change de
page ?



Merci d'avance,

Eric.



"Gilles TOURREAU" a écrit dans le message de
news:
Le Fri, 13 Apr 2007 11:47:10 +0200, Eric a écrit:

Bonjour à tous,

je developpe un site web (application) en asp.net (framework 2)
et chez certains de mes clients (ceux ou l'activité est plus intense),
l'erreur suivante : systemOutOfMemoryException revient regulierement
...
on tue le process asp.net et/ou redemarre IIS et ça repart mais bon ...
Dans mon code il y avait pas mal de try catch utilisés comme des if
else
... serait-ce lié ?
sinon avez vous des pistes ?

merci pour infos,
Eric.





Pouvez vous poster une partie de vos try/catch ?

Cordialement

--
Gilles TOURREAU


S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr





Eviter dans un premier temps d'utiliser les try/catch pour "tester une
valeur", cela consomme beaucoup de ressources CPU...
Les exceptions sont là uniquement pour être déclenché lors d'une erreur de
programmation...

Ce genre de code pour ouvrir un fichier par exemple est déconseillé :

Try
File.Open(...)
Catch
Message("Nom de fichier incorrect");
End Try

Il faut mieux écrire :

If File.Exists(...) = False Then
Message("Nom de fichier incorrect");
Else If VérifierDroitFichier(...) == False
Message("Vous n'avez pas le droit d'ouvrir le fichier...")
Else
Try
File.Open(...)
Catch
Message("Oups... Erreur de programmation... Le développeur a oublié
de vérifier quelque chose...");
End Try
End If

Utiliser donc toujours des If/Else... Dans la théorie absolue il devrait
jamais avoir de try/catch dans le code d'une application, mais juste un au
niveau "global" de l'application, afin de signaler à l'utilisateur qu'il y
a un bug (ou au niveau thread si on peut arrêter une partie de
l'application)...

Le second défaut de votre code, si vous faite un Try/Catch ou
Try/Catch(Exception) vous allez "choper" toutes les exceptions qui sont
déclenché ! Et donc aussi celle qui concerne les "erreurs brutes" de
codage tel que : ArgumentNullException (passage d'un paramètre null à une
méthode), NullReferenceException (Référence à une variable null) :

Si on applique votre code ainsi :

Try

Donne_Numero_Commande = DR.GetValue(0)

Catch

Donne_Numero_Commande = ""

End Try

Imaginons que DR = null, vous ne verrez pas cette erreur se déclencher (à
l'execution et au débogage !!!) et automatiquement le code du Catch sera
déclenché. En résumé vous avez traité une exception qui n'aurait pas du
l'être !
Donc spécialisez toujours vos exceptions par :

Try
...
Catch (FileNotFoundException)
...
Catch (FormatException)
...
End Try

Ainsi dans ce code, en cas de déclenchement de NullReferenceException,
tout saute et suffit de corriger !

Et le 3ème point concernant qui peut être du au OutOfMemoryException :
Utilisez la clause Finally afin de libérer les ressources "Disposable"
(implémentant la classe IDisposable) afin que celle-ci soit déclenché avec
ou sans exception...

OuvrirConnexion()

Try
Remplir(DataTable)
Catch
...
Finally
FermerConnexion();

Le mieux c'est d'utiliser la directive using ainsi :

Try
Using(OuvrirConnexion())
{
Remplir(DataTable)
}
Catch
...

L'OutOfMemoryException peut être du à cette non libération de ressources
correct...

Pour en finir, j'ai eu un collègue qui a eu ce genre de problème à cause
d'un traitement exception qui faisait tourner le programme à l'infini
(pendant 10 sec, et après OutOfMemoryException...) tout çà parceque il
avait fait un Try/Catch(Exception) qui englobait toutes les exceptions. Le
programme tournait donc constamment pendant 10 sec alors qu'il aurait du
planter depuis longtemps...

J'espère que je vous ai un peu éclairait...
Excusez moi encore de ma syntaxe au niveau du code, mais je suis
développeur C#...

Cordialement

--
Gilles TOURREAU


S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr