Je suis en train de debug de travail qui traite de gros fichiers. Le code fonctionne, mais il y a des erreurs sporadiques sont signalés dans les .NET Runtime lui-même. Pour le contexte, le traitement ici est de 1,5 GO de fichier (chargé en mémoire qu'une seule fois) d'être traitée et diffusée en boucle, délibérément, pour essayer de reproduire ce imprévisible d'erreur.
Mon test fragment est en gros:
try {
byte[] data =File.ReadAllBytes(path);
for(int i = 0 ; i < 500 ; i++)
{
ProcessTheData(data); // deserialize and validate
// force collection, for tidiness
GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);
GC.WaitForPendingFinalizers();
}
} catch(Exception ex) {
Console.WriteLine(ex.Message);
// some more logging; StackTrace, recursive InnerException, etc
}
(avec un peu de timing et d'autres trucs jetés dans)
La boucle processus d'amende pour non-déterministe nombre d'itérations pleinement avec succès - aucun problème; ensuite, le processus va s'arrêter brutalement. Le gestionnaire d'exception n'est pas atteint. Le test n'impliquent beaucoup de l'utilisation de la mémoire, mais il ne voyait-dents très très bien lors de chaque itération (il n'est pas évident de fuite de mémoire, et j'ai beaucoup de dégagement à la tête - 14GB inutilisés mémoire primaire au pire point en dents de scie). Le processus est en 64 bits.
L'erreur windows-journal contient 3 nouvelles entrées, ce qui (par l'intermédiaire de code de sortie 80131506) suggèrent un Moteur d'Exécution d'erreur - une vilaine petite bête. Une réponse similaire, suggère un GC erreur, avec un "fix" pour désactiver simultanées GC; cependant cette "solution" n'empêchent pas la question.
Clarification: ce faible niveau de l'erreur de ne pas frapper l' CurrentDomain.UnhandledException événement.
Clarification: l' GC.Collect est là que pour surveiller la scie à denture de mémoire, à vérifier pour les fuites de mémoire et de garder les choses prévisibles, l'enlever n'est pas le problème: elle permet simplement de garder plus de mémoire entre les itérations, et rend le dmp des fichiers plus ;p
En ajoutant de la console de traçage, j'ai observé qu'il défaillant au cours de chacune de:
- lors de la désérialisation (beaucoup de dotations,...)
- au cours de GC (entre une table "approche" et une table "complète", à l'aide de la GC API de notification)
- au cours de validation (juste
foreach- dessus de certaines des données) - curieusement , juste après un GC "complet" lors de la validation
Beaucoup de scénarios différents.
Je peux obtenir un crash dump (dmp) des fichiers; comment puis-je étudier cette question plus loin, pour voir ce que le système est en train de faire lorsqu'il échoue spectaculairement?
