|
| Plantage aléatoire, souvent sans message. Gestion mémoire ? |
| Iniciado por Pierre, jan., 31 2025 3:01 PM - 2 respostas |
| |
| | | |
|
| |
Membro registado
181 mensagems |
|
| Publicado em janeiro, 31 2025 - 3:01 PM |
Bonjour,
Depuis un certain temps j'ai des plantages aléatoires d'une application en WD28
L'appli, un exe 32 bits, se ferme inopinément, souvent sans message. Parfois "une erreur interne inattendue est survenue"
Toujours dans WD280vm.dll
Dans les logs Windows, c'est aussi toujours cette dll qui est référencée.
Cette appli vient de WD26, est passée par WD27 et finalement WD28 J'ai 2024 & 2025 mais je ne suis pas convaincu que passer à 2024 va régler l'affaire. Peut-être à tort ?
L'application est construite sur +- 70 classes. Certaines contiennent des classes comme membres.
Certaines instanciations sont dynamiques, d'autres pas.
Sur le poste de développement, jamais de soucis mais je n'utilise peut-être pas assez longtemps si c'est un problème de fuite mémoire.
J'ai réussi à isoler et limiter un plantage qui survenait à l'exécution d'une méthode de classe membre d'une classe principale.
Voici un résumé de la classe :
CDossier est une Classe
hérite de CModeleBase
m_nIDCommercial est un entier <MAPPING=IDCommercial>
m_pclClient est un CClient dynamique
m_pclVéhicule est un CVéhicule dynamique
m_pclCommercial est un CLogin dynamique
m_pclContacts est un CDossierAdressesLst dynamique
m_pclFactures est un CFacturesLst dynamique,Sérialise = Faux
m_clTauxTVA est un CTvaMngt,Sérialise = Faux
FIN
CFacturesLst est une Classe
hérite de CGererListe
m_clItem est un CFacture
m_tabItems est un tableau de CFacture
m_tabItemsToDelete est un tableau de CFacture
m_tabItemsFiltered est un tableau de CFacture
FIN
En appelant, dans Fin initialisation fenêtre, la méthode
CDossier.CFactureLst.ChargerSuivantDossier()
L'exe plantait
Si je fait
MaCliste est un CFactureLst
MaListe.ChargeSuivantDossier
CDossier.FactureLst<-Maliste çà fonctionne
J'en arrive à soupçonner la gestion de mémoire
J'ai probablement loupé quelque-chose dans ma façon d'instancier les classe (statique/dynamique) Phénomène invisible au début et qui fini par apparaître avec le grossissement du projet.
Voilà, je suis à votre disposition pour répondre aux questions.
toute piste qui me permettra d'isoler le problème ou mieux le résoudre sera la bienvenue
Pour les spécialiste des classes, une idée des bonnes pratique pour éviter les débordements ?
Merci d'avance pour votre aide
--
Pierre
--
Pierre |
| |
| |
| | | |
|
| | |
| |
Membro registado
1.009 mensagems |
|
| Publicado em fevereiro, 01 2025 - 11:10 AM |
| |
| |
| | | |
|
| | |
| |
Membro registado
181 mensagems |
|
| Publicado em fevereiro, 03 2025 - 10:27 AM |
Merci Cédric pour votre retour
La DLL avec les fuites mémoire corrigées fait déjà partie de ma version mais je vais investiguer au départ du forum actuel.
J'aurais aimé tester en 64 bit mais l'application utilise une dll externe uniquement dispo en 32
Je remettais aussi en question la façon de construire mes classes. C'est d'ailleurs le principal but de ma question.
Cordialement,
--
Pierre |
| |
| |
| | | |
|
| | | | |
| | |
|