Erreur défaillance du tas DLL

Bonjour à tous,

J'ai développé en C++ une DLL permettant de contrôler un fichier Microsoft Excel (.xls).
J'ai effectué plusieurs tests pendant le développement et j'ai validé son fonctionnement.
J'ai ensuite ajouté ma DLL à mon programme, et je fais une boucle de lecture de lignes du fichier (il y a 1224 lignes).
La lecture se fait correctement et et je récupère bien toutes mes informations.
Seulement, à la sortie de la boucle, le message suivant apparait :
Windows a déclenché un point d'arrêt dans test.exe.
Cela peut être dû à une défaillance du tas qui indique un bogue dans mice.exe ou l'une des DLL chargées.
Cela peut également être dû à l'appui sur la touche F12 lorsque mice.exe a le focus
La fenêtre Sortie peut contenir des informations de diagnostic supplémentaires.
J'ai donc vérifié toutes les allocations et libérations de ma DLL sans résultats.
Je suis a cours d'idées, si quelqu'un à un conseil, il sera le bienvenu !

Un thread ne peut pas supprimer des données instanciées par un autre : vérifie bien que ce n 'est pas le cas dans ton programme.

J'ai bien cherché de ce coté la mais sans résultats.
Existe t'il un utilitaire VS ou un logiciel gratuit pour rechercher ce type d'erreur?
J'utilise des objets VARIANT. Le problème pourrait-il venir de ces objets?

Pas que je sache en tout cas :?

Pour palier à ton soucis je te conseille de mapper les allocations et désallocations derrière des points d'entrées de ta DLL.
Par exemple NewMachin et DeleteMachin qui dans leurs implémentations feront appel à theApp.New et theApp.Delete, afin que ce soit le thread de la DLL et lui-seul qui gère tout. Après à toi de remplacer partout tes manipulations de mémoire par ces appels.
Tu me suis ?

Je ne te suis pas !
Tu veux parler d'instancier l'application Excel par ma DLL c'est bien sa?
Si oui c'est déja le cas

Montre ton code (DLL + les appels qui y sont faits).

Je suis désolé mais je n'ai pas l'autorisation de le faire. :?
De plus ma DLL fait plus de 1000 lignes :?
Mais j'ai peut être une piste !
J'utilise la fonction CLSIDFromProgID puis CoCreateInstance pour lancer Excel.
Existe-il une fonction pour libérer la mémoire par la suite?
J'utilise void Release( ) throw( );

Une instanciation non suivie d'une libération provoque une fuite mémoire, pas une corruption du tas comme tu sembles avoir.
Par contre essayer de supprimer dans un tas qui n'est pas le tien provoque ce type d'erreur.

Sans précision complémentaire concernant ce que tu fais je ne vais pas pouvoir plus t'aider.

Cet algo est éxecuté par le programme qui utilise ma DLL :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

Début Initialisation d'Excel (méthode de la DLL) Si initialisation ok alors Ouverture du fichier (méthode de la DLL) Si ouverture ok alors pour i allant de 1 à NbLignes faire pour i allant de 1 à NbColonnes faire Lire la cellule (méthode de la DLL) enregistrement dans un stringstream fin pour fin pour Fermeture du fichier (méthode de la DLL) fin si (ouverture) Le programme s'arrête ici Fermeture d'Excel (méthode de la DLL) fin si (initialisation) Fin

---

La DLL fait partie de mon projet et j'utilise le mode Debug. En cas d'erreur dans la DLL le programme s'arréterai dans la méthode (de la DLL) posant problème et non à la fin de la boucle du programme utilisant cette DLL.

Citation:

---

Lire la cellule (méthode de la DLL)
enregistrement dans un stringstream

---

à mon avis c est là que ça pêche : montre moi ce code (DLL + appel du programme principal) ou tout du moins ce que tu pourras. Où est déclaré la string ?

Citation:

---

En cas d'erreur dans la DLL le programme s'arréterai dans la méthode (de la DLL) posant problème et non à la fin de la boucle du programme utilisant cette DLL.

---

pas forcément

Commence par vérifier avec des points d'arrêt que tu as bien récupéré tes valeurs en sortie de boucle. Si ce n'est pas le cas tu sauras que tu as circonscrit l'erreur.

Si en sortie des 2 boucles for tu as tout ce qu'il te faut alors essaye de commenter la ligne suivante.

Bon courage ;)

J'ai bien récupéré toutes mes valeurs dans mon flux en sortie de boucle.
En commentant la ligne suivante l'erreur est la même

Citation:

---

J'ai bien récupéré toutes mes valeurs dans mon flux en sortie de boucle.

---

tu parles bien de ssFICDEV (dans le code que tu m'as anvoyé en mp) ? déclaration de cette variable ? que doit-elle contenir en sortie de la 2ème boucle for ? nombres d'octets ?

Citation:

---

Envoyé par TheGzD

tu parles bien de ssFICDEV (dans le code que tu m'as anvoyé en mp) ?

---

Oui

Citation:

---

déclaration de cette variable ?

---

stringstream ssFICDEV;

Citation:

---

que doit-elle contenir en sortie de la 2ème boucle for

---

Le contenu du fichier

Citation:

---

nombres d'octets ?

---

Cela dépent de la taille du fichier

Citation:

---

Citation:

---

déclaration de cette variable ?

---

stringstream ssFICDEV;

---

pourquoi ne pas avoir pris un std::string comme tu as fait pour d'autres variables ?
Où est déclaré la variable ? visibilité ?

Citation:

---

Citation:

---

que doit-elle contenir en sortie de la 2ème boucle for

---

Le contenu du fichier

Citation:

---

nombres d'octets ?

---

Cela dépent de la taille du fichier

---

oui ça je m'en doute bien, mais je ne te demande pas ce que tu aimerais bien que ça contienne mais ce que ça contient réellement (en particulier dnas le cas où ça ne marche pas) sous la forme explicite de valeurs (contenu + taille).

D'autre part j'ai pu constater que tu utilisais des opérateurs de flux, qui plus est dans des fonctions statiques de ta DLL. Essaye plutôt de réaliser tes appels en instanciant un objet dont ces fonctions seraient des méthodes.

Citation:

---

Envoyé par TheGzD

pourquoi ne pas avoir pris un std::string comme tu as fait pour d'autres variables ?
Où est déclaré la variable ? visibilité ?.

---

La suite du programme m'oblige à utiliser un stringstream.
La variable est déclarée avant l'initialisation d'Excel, dans la même fonction

Citation:

---

oui ça je m'en doute bien, mais je ne te demande pas ce que tu aimerais bien que ça contienne mais ce que ça contient réellement (en particulier dnas le cas où ça ne marche pas) sous la forme explicite de valeurs (contenu + taille).

---

la taille du flux renvoyée par sizeof est de 136 bytes

Citation:

---

D'autre part j'ai pu constater que tu utilisais des opérateurs de flux, qui plus est dans des fonctions statiques de ta DLL. Essaye plutôt de réaliser tes appels en instanciant un objet dont ces fonctions seraient des méthodes

---

Qu'est-ce que cela changerait?

Citation:

---

La variable est déclarée avant l'initialisation d'Excel, dans la même fonction

---

déclarée dans une fonction statique de ta DLL ?!? :aie:

Citation:

---

Citation:

---

D'autre part j'ai pu constater que tu utilisais des opérateurs de flux, qui plus est dans des fonctions statiques de ta DLL. Essaye plutôt de réaliser tes appels en instanciant un objet dont ces fonctions seraient des méthodes

---

Qu'est-ce que cela changerait?

---

pour les mêmes raisons que le point cité précédemment : qui possède qu'elle variables/attributs ? quel thread manipule quoi ? là c'est un peu n'importe quoi, d'où tes problèmes.
Quand ta chaîne est redimensionnée (lors de l'appel à l'opérateur de flux) qui réalloue l'espace ? quel thread ?
On en revient à la première chose que je t'avais dites, à savoir :

Citation:

---

Un thread ne peut pas supprimer des données instanciées par un autre : vérifie bien que ce n 'est pas le cas dans ton programme.

---

Quand on fait du C++ on utilise des objets et on évite les statiques tout moches :wow:

Je passe sur l'ensemble des erreurs et autres contre-vérités qui m'ont fait pleurer les yeux pendant le survole de ce file de message.:cry:

Commençons par mettre le clocher au centre du village.

Windows(le Kernel) ne déclenche jamais de point d'arrêt.

C'est quoi ce "test.exe" ou "mice.exe" ?

Si vous faite une "dll" xla, c'est Excel qui est lancé pas un autre programme.

Le message d'erreur est justement la manifestation de l'outil intégré à la C-Runtime Débug livrée avec VS.

Cette C-Runtime vérifie régulièrement (configurable) que les tas de l'application utilisant cette C-runtime ne sont pas corrompu. Cette C-Runtime permet aussi de détecter des dépassements dans les écritures dans les blocs alloués dans ces tas, etc.

Donc le message n'est pas un problème mais la manifestation de l'outil pour vous aider à corrigé le problème.

Donc commencez par configurer l'outil (le C-Runtime en Débug) pour faire systématiquement les vérifications. Ainsi, en utilisant le débuggeur de VS, votre programme s'arrêtera dés la première allocation ou désallocation de mémoire qui suit l'endroit où votre code fait n'importe quoi en mémoire.
Il vous indiquera aussi le contenue de la mémoire qui pose problème.

Pour faire ces vérifications systématiquement : http://msdn.microsoft.com/en-us/libr...v=VS.100).aspx