Problème Exécution Plusieurs Instances Appli / DLL

Version imprimable

13/06/2008, 11h45
Fab62_

Problème Exécution Plusieurs Instances Appli / DLL

Bonjour,

Voilà comment se décompose l'application:
- Un exe sous forme de console WIN32
- Une DLL multihreadée (vu que j'utilise des threads), utilisant les MFC dans une DLL partagée

(Tout deux développés en C++ sous VS2003, MFC 7.1)

Je réalise correctement mon interfaçage et l'application fonctionne parfaitement si je l'exécute unitairement.

Lorsque je lance 2 fois mon exe et au moment où j'entre dans la section où j'utilise la DLL, j'ai une erreur de type:

Citation:

L'instruction à "0x...." emploie l'adresse mémoire "....". la mémoire ne peut être "read".

Je suppose donc qu'il y a un problème de partage de données mais je pensais que vu que j'exécute 2 process "distrincts", je n'aurais pas de problème de ce genre.
Ils ne sont peut-être pas si distincts que ça...:?

Y aurait-il un paramètre d'application à modifier? ou autre(s) mécanisme(s) éventuel(s) ?
13/06/2008, 11h57
Médinoc

Fais-tu appel à une quelconque fonction de partage de données, ou de communication inter-procesus dans ta DLL ?
Car en effet, il s'agit de deux processus différents...

Ou bien, ta DLL cherche peut-être à accéder en écriture à un fichier, causant des problèmes de lock...
Ou encore, peut-être utilises-tu des objets de synchronisation nommés pour synchroniser tes threads entre eux?
13/06/2008, 13h44
Fab62_
En gros, le but de l'ensemble est de traiter un fichier spécifié puis de fournir un fichier de sortie.

Lorsque j'exécute deux instances de mon application pour traiter deux fichiers différents, j'ai donc l'erreur décrite précédemment.

Techniquement,

les synchronisations:
- Au sein de ma DLL:
j'ai des synchro inter-threads par CSemaphore et CEvent
- Entre ma DLL et mon appli:
J'ai quelques synchro avec des CEvent nommés

les fichiers:
- Fichier source:
Chemin spécifié en paramètre, il est ensuite mappé en mémoire par tronçons via un CMemFile
- Fichier de sortie:
Il est écrit à la fin du traitement, CStdioFile.

Est-ce que l'un et/ou l'autre des éléments serait la raison du problème ?
13/06/2008, 14h39
Médinoc

Je pense que tes events nommés sont la source du problème, car ils traversent la barrière entre les processus.
13/06/2008, 15h18
Fab62_

Ca à l'air d'être cohérent mais dommageable pour moi...

S'il n'y a pas de solution, il faudrait que je verrouille la possibilité de lancer plus d'une fois mon exe console Win32... comment peut-on faire ça ?
13/06/2008, 15h30
Aurelien.Regat-Barrel

Pourquoi ne pas demander au debogueur de localiser le probleme? Si tu conserves le .pdb genere avec ta dll, il ne devrait pas y avoir de probleme...
13/06/2008, 15h32
Médinoc

Je pense que la "bonne" chose à faire, c'est soit utiliser des events anonymes, soit ajouter l'ID de processus au nom...
13/06/2008, 16h25
Fab62_

Concernant le ".PDB", je ne sais pas comment l'utiliser. Mais si c'est possible d'utiliser le debugger, ça serait parfait en effet.... mais je ne sais pas comment faire vu que je dois lancer 2 instances de l'appli pour que ça plante...

Par rapport la modif du CEvent, oui, il faudrait que les noms soit uniques pour rester dans le giron du couple {Instance appli - dll}.
Il faudrait donc que des deux côtés je connaisse l'ID du processus...:roll:...soit modifier mes méthodes d'interface.

Merci bien de vos réponses, je vais essayer en tout cas!
13/06/2008, 16h29
Médinoc

L'ID du processus est TOUJOURS accessible. Il te suffit d'utiliser la fonction GetCurrentProcessId().
14/06/2008, 11h45
Aurelien.Regat-Barrel

Citation:

Envoyé par Fab62_

Concernant le ".PDB", je ne sais pas comment l'utiliser. Mais si c'est possible d'utiliser le debugger, ça serait parfait en effet.... mais je ne sais pas comment faire vu que je dois lancer 2 instances de l'appli pour que ça plante...

Eh bien... lance deux instances! :D
La premiere en dehors du debogueur (CTRL + F5), la seconde depuis le debogueur. Ou les deux en dehors du debogueur, et tu attaches le debogueur a l'instance qui crash au moment du crash. Le .pdb a juste a se trouver au meme endroit que la dll, c'est tout.
16/06/2008, 09h44
Fab62_

Merci !
Avec les éléments que vous m'avez donné je m'en suis sorti.

Les évènements doivent être nommés de manière unique au processus. Comme le dit la MSDN, leur portée va au delà des frontières du processus d'où les incohérences lorsque deux instances de mon application étaient exécutées.

Je corrige donc en récupérant l'ID du processus lancé pour identifier chacun des évènements.

J'observe simplement une perte en performance mais ça doit être autre chose...

Merci encore et bonne continuation.
:king: