Discussion :

[Fab62_]

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:

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) ?

[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?

[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 ?

[Médinoc]

Je pense que tes events nommés sont la source du problème, car ils traversent la barrière entre les processus.

[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 ?

[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...