Discussion :

[LoGGi]

Salut à vous

J'ai aussi ce type de pb de violation d'accès lorsque j'appelle une méthode de ma dll.

J'ai développé des plugins (des .dll sous win32) que je souhaite charger dynamiquement dans mon appli de test.
Tous mes plugins sont basés sur une même interface Plugin.h, que j'ai déclaré comme tel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
#ifndef _PLUGIN_H_
#define _PLUGIN_H_
 
# ifdef WIN32_DLL
# 	define WIN32_PLUGIN_API __declspec(dllexport)
# else
# 	define WIN32_PLUGIN_API
# endif
 
#include "../DeviceManager.h"
 
class WIN32_PLUGIN_API Plugin {
 
public:
 
	/*my virtual methods to be redefined*/
 
};
 
/*!
 * \Class PluginFactory
 *
 * PluginFactory just contains informations concerning a plugin
 * It's separated from the Plugin class to make the disctinction between the informations of the plugin and the communication methods
 * 
 */
 
class WIN32_PLUGIN_API PluginFactory {
public:
	virtual std::string getPluginName()=0;
	virtual std::string getPluginVersion()=0;
	virtual std::string getPluginAuthor()=0;
	virtual Plugin *getInstance(DeviceManager *controller)=0;
};
 
extern "C" {
WIN32_PLUGIN_API PluginFactory* createFactory();
}
 
#endif //_PLUGIN_H_

J'ai donc compilé mes plugins en utilisant l'option WIN32_DLL et généré les dll correspondantes.
Jusque là tout va bien je pense...


Je souhaite donc utiliser l'explicit linking pour charger mes plugins dans mon appli de test.
Au démarrage je charge mes dlls dans le but de remplir une map<pluginName, pluginInstance> ...
Mais voilà au premier appel à la méthode de plugin qui doit me retourner le nom du plugin (pluginFactory->getPluginName()) : violation d'accès.

Voilà le code qui charge les plugins :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
 
#ifdef _WIN32
#include <windows.h>
#include <tchar.h> 
#include <strsafe.h>
#else
#include <dirent.h>
#include <dlfcn.h>
#endif
 
typedef PluginFactory* (*OpCreation)();
 
 
/****************************************/
//PluginFactories
 
#ifdef _WIN32
 
void PluginFactories::loadPlugins(std::string path) {
	//std::string dllpath = path + "\\*.dll";
 
	WIN32_FIND_DATA File;
	HANDLE liste;
	TCHAR szDir[MAX_PATH];
    size_t length_of_arg;
 
	StringCchLength(path.data(), MAX_PATH, &length_of_arg);
	StringCchCopy(szDir, MAX_PATH, path.data());
	StringCchCat(szDir, MAX_PATH, TEXT("\\*.dll"));
 
	liste = FindFirstFile(szDir, &File);
 
	if(liste == INVALID_HANDLE_VALUE)
		std::cerr << "FindFirstFile failed" << std::endl;
 
	do {
 
		std::string tmp = path + "\\" + (std::string)File.cFileName;
		std::cout << tmp << std::endl;
 
		HINSTANCE lib = LoadLibrary(tmp.c_str());//charge le plugin
 
		if (!lib) {
			std::cerr << "LoadLibrary failed: " << GetLastError() << std::endl;
			continue;
		}
 
		OpCreation createFactory = (OpCreation) GetProcAddress(lib, "createFactory");//lie la dll au symbole
 
		if (!createFactory) {
			std::cerr << "GetProcAddress failed: " << GetLastError();
			continue;
		}
 
		PluginFactory *pluginFactory = (*createFactory)();
		if (!pluginFactory) {
			continue;
		}
 
		factories[pluginFactory->getPluginName()] = pluginFactory;
 
	} while ((FindNextFile(liste, &File)));
	// FindClose() ferme la recherche
	FindClose(liste);
 
}

Avant de travailler sous VC++ 2008 express , j'utilisais un Makefile et là surprise tout fonctionne !
Je pense donc que ca vient d option de compil et j'ai comparé celles de mon Makefile (c à dire aucune à part /EHsc et /W3) et celle des lignes de commande de vc++ (yen a bcp). J'ai donc retiré une à une les options dans vc++ pour que les lignes de commande ressemblent à celle de mon Makefile.

Rien y fait

J'ai abso besoin de ce proj vc++ et ne sais pas comment faire, y aurait il d'autre chose à activer dans vc++ pour utiliser d dll dynamiquement ?

Merci d'avance pour vos réponses
et désolé pour le roman mais j'essaye d'être le plus précis possible.

[Médinoc]

Je te conseillerais d'éviter les std::string dans l'interface d'une DLL (et tous les types de la STL, en fait).

Tu auras moins de problèmes en retournant un char*, ou si tu es familier avec COM, une BSTR.

Essaie aussi d'utiliser le debugger pour en savoir plus sur le plantage (notamment la stack trace).

[LoGGi]

Dabord merci pour ta réponse rapide

Je te conseillerais d'éviter les std::string dans l'interface d'une DLL (et tous les types de la STL, en fait).

-C bon à savoir pour la prochaine mais sur cette interface j'utilise les types std à donf, les string mais aussi les vector et les map qui sont bien pratiques (par quoi remplacer ces 2 derniers ?) quasi ds toutes mes méthodes .

Disons que je ne peux pas ou plus me permettre d'effectuer de tels modifs.

Tu auras moins de problèmes en retournant un char*, ou si tu es familier avec COM, une BSTR.

-Pour quelles raisons ?
J'essaye de faire du code multiplateforme, les type du COM sont compatibles ailleurs que WIN ?

Essaie aussi d'utiliser le debugger pour en savoir plus sur le plantage (notamment la stack trace).

-J'ai deja essayé de placer des breakpoint mais je tombe directo sur du code machine et dans la pile des appels, je n'ai pas dautre info que :
DeviceManagerTest.exe! ...et une adresse.
...
...
ect

La fenêtre de sortie m'indique :

DeviceManagerTest.exe', Le fichier binaire n'a pas été généré avec les informations de débogage.

Comment activer les infos de debug ?

[LoGGi]

Les infos de debug g trouvé :
Propriétés de config / Editeurs de liens / Debogage / et générer les infos de débogage
Tout simplement avait po vu

[Médinoc]

Je crois que tu compiles en Release, en fait. Compile dans la configuration "Debug Win32" et tu auras TOUTES les infos de débogage nécessaires.

Sinon pour ta question, c'est parce qu'il y a plusieurs versions de la bibliothèque run-time (qui contient la STL), et elles tendent à être incompatibles entre elles, ce qui cause des erreurs bizarres (souvent sous la forme d'étranges plantages) quand deux modules utilisant des versions différentes tentent de communiquer.

[bacelar]

Rien n’empêche de fournir avec le header définissant l'interface de plugin utilisant des types simples des fichiers contenant des classes wrappers utilisant des types de la STL.

Cela permettra d'utiliser une API non sujet aux problèmes d'implémentation de la STL toute en utilisant une API STL-aware via les classes de wrapping.

[LoGGi]

Salut je reviens a la charge

Merci a vous 2 pour vos rep

à Bacelar :
les classes de wrapping ce sont juste des classes de conversion ?

à Médinoc :
J'ai passé la soirée à debug mais je ne peux pas aller plus loin dans la stack trace que l'appel à une des méthode de ma dll.
J'ai quand même constaté que le plantage se fait sur l'appel à getPluginName() qui est la première appelée de ma dll ET qui doit me retourner le nom du plugin sous la forme d'une STD::STRING (aïe).
J'ai vérifié je rentre bien ds cette méthode mais là exception de violation d'accès !
En fait elle retourne nimporte nawak : it Ê♣ùw8☺╚ ♠

Du coup j'ai remplacé cet appel par le nom en dur de mon plugin et la ca passe, j'ai même ma méthode pluginLaunch() (sans retour ni params) qui est bien exécutée.
Et l'appel à la méthode suivante qui dans laquelle je passe une std::string et une std::map replante
c donc bel et bien un pb de std

Ce que je ne comprends pas c pk qd j'utilise l'invité de commande de vc++ 2008 et que je fais mon make dans lequel j'ai fais un copicoll des ligne de commande de vc++ (cl.exe et link.exe) après avoir réduit au max les options, g plus de plantage

Ca vient pt de des réglages qui ne sont pas visible ds les option de compil comme ds propriétés de config./général/param par défaut ???
Et ds propriétés de config./C/C++/Génération de code/Biblio runtime la quelle choisir ?
Il doit bien y avoir un moyen
Si vous avez la moindre idée ou remarque je suis preneur parce que là je suis québlo !

[bacelar]

Tous les symptômes sont cohérents avec un schisme dans la stl.
Vous pouvez utiliser deux implémentation de la STL de chaque côté (exe et dll).
Vous pouvez aussi avoir des options de compilation différentes de chaque côté qui influence le code généré par la même STL, générant deux code différents avec les mêmes sources.
Etc..

C'est pour cela qu'on vous conseille de ne pas utiliser la stl dans les APIs.

Donc les wrappers peuvent vous y aider.

Un exemple

Sans:
dans le .h de l'API

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::string getName();

Avec:
dans le .h de l'API

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LPCSTR _getName();

et vous avez, dans un .h Wrapper, quelquechose du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::string getName(return std::string(_getName());)

[LoGGi]

Oui merci Bacelar pour ces infos mais le problème c que ne sachant pas cela qd j'ai développé mon API (je travaillais sous OSX et n'avais pas ce type de prob), j'ai utilisé la stl a foison et donc utiliser les wrappers m'obligerait à quasi tout recoder !

D'autant plus que j'utilise aussi a fond les map et vector, par quoi les remplacer ceux là ?

Et le dernier point qui fait que je ne peux vraiment pas c que 3 plugins ont été dév sur ce modèle 1 par moi même mais aussi 2 autres par d'autres personnes.

Il faut vraiment que je trouve un autre moyen et de plus je le répète avec mon fichier Makefile cela fonctionne ainsi que sur OSX et Linux. Il n'y a vraiment que sur ce bip d'environnement vc++ que j'ai ces pb de stl.

Enfin merci qd même Bacelar, et au passage les LPCSTR, ce sont bien des types windows et ils ne sont pas compatibles sur le autres env?

[Médinoc]

La différence peut être aussi simple que "l'un des deux compilés en Debug, l'autre en Release".

Aussi, attention quand on retourne un char const * (ou LPCSTR, qui est la même chose) : Il faut savoir si la chaîne doit être détruite ou pas.

Je pense que c'est pour cette raison que l'API Windows utilise plutôt des BSTR (qui doivent toujours être détruites) ou des pointeurs vers un buffer:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
class IPlugin
{
public:
	size_t getName(
	 char *buf,    //[out/opt] Si non-nul, on y met le nom. Toujours terminé par un caractère nul quand la fonction retourne.
	 size_t taille //[in]Taille du buffer, caractère nul compris.
	 ) = 0; //Retourne toujours la taille requise, caractère nul compris.
};

[bacelar]

Pour les Wrappers, il suffit d'ajouter le ou les wrappers dans le .h de l'API.
Il n'y aura aucune modification dans le code utilisant la librairie.

Pour les types complexes, il faudrait enrichir l'API pour que les wrappers puis implémenter les actions de manière adéquate et transparente pour les utilisateurs de l'API qui ne vous que les wrappers.

L'utilisation des wrappers permet d'utiliser n'importe quelle implémentation ou configuration de la stl de chaque côté.
Vous n'avez pas eut de problème sur les autre système car vous avez utilisé des chaînes de compilations bien moins ouverte que VS (plus fermé que Windows ).
Si vous commencez à customiser ces environnements, vous aurez vraisemblablement les mêmes emm*****.

Si vous êtes près à gérer le fait que vos clients et vos plugIns soient soudés à une version configuration particulière d'un compilateur particulier avec une STL encore plus particulière, ce qui est pour moi rédhibitoire, il faut que vous maîtrisiez la stl utilisée et les constantes de compilation définies au moment de la compilation de l'exécutable et de tous les plugIns.
Cela doit être la même STL et les mêmes constantes de compilation (celles ayant une action sur la STL, dans le doute toutes). Debug et Release font partie des constantes de compilation influençant énormément l’implémentation de la STL.

[LoGGi]

Pour les Wrappers, il suffit d'ajouter le ou les wrappers dans le .h de l'API.
Il n'y aura aucune modification dans le code utilisant la librairie.

-Ca je l'ai compris mais bon nombre des méthodes de mon API retournent ou ont en parametres des std::string.
Ce que je voulais dire c que je dois avec cette méthode remplacer tous les std::string par des LPCSTR dans mon interface Plugin.h ET dans les 3 plugins déjà dèv. Ce que je ne peux pas faire puisque je n'ai pas le code de 2 des plugins...bref ca c mon problème...

Si vous êtes près à gérer le fait que vos clients et vos plugIns soient soudés à une version configuration particulière d'un compilateur particulier avec une STL encore plus particulière, ce qui est pour moi rédhibitoire, il faut que vous maîtrisiez la stl utilisée et les constantes de compilation définies au moment de la compilation de l'exécutable et de tous les plugIns.

-Je ne suis pas du tout prêt a gérer ce fait puisque je galère sur ces configs depuis 3j et puis ce n'est biensur pas le but car je voudrai que n'importe quel dév puisse créer son propre plugin et que de l'autre coté n'importe quel dév puisse utiliser ces plugins sans s'embêter avec ça.

Cela doit être la même STL et les mêmes constantes de compilation (celles ayant une action sur la STL, dans le doute toutes). Debug et Release font partie des constantes de compilation influençant énormément l’implémentation de la STL.

-
Génération de ma dll :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
cl.exe /c /Od /FD /EHsc /W3 /MT /Zi /TP /DWIN32_DLL /FoMinuit.obj Minuit.cpp
link.exe /dll /out:Minuit.dll /implib:Minuit.lib /DEBUG Minuit.obj

Génération en mode debug de mon éxecutable qui l'utilise dynamiquement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
cl.exe /Od /FD /EHsc /MT /Fo"Debug\\" /W3 /nologo /c /Zi /TP /D"WIN32" /D "_WIN32" /D"DEBUG"
link.exe /OUT:"DeviceManagerTest.exe" /MANIFEST:NO /DEBUG *.obj

C quand même bien ressemblant comme génération.
Dernier truc que j'ai pas testé c'est de générer ma dll à partir de vc++ (jutilisais un Makefile jusqu'à maintenant) et si il faut je générais ma dll en mode release (je ne sais pas comment spécifier le mode debug à partir d'un Makefile...

Et puis Inch'Allah
en tout cas merci pour toutes les infos

[bacelar]

Bin déjà dans la ligne de commande du cl.exe pour la dll, je ne vois pas de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/D"DEBUG"

Comme la STL, c'est quasiment que des templates, c'est le compilateur qui est le plus influent de le code généré. Et ce "/D"DEBUG"", c'est une très très gros différence.

Essayez donc avec /D"DEBUG" partout ou nulle part, mais pas de mélange.

-Je ne suis pas du tout prêt a gérer ce fait puisque je galère sur ces configs depuis 3j et puis ce n'est biensur pas le but car je voudrai que n'importe quel dév puisse créer son propre plugin et que de l'autre coté n'importe quel dév puisse utiliser ces plugins sans s'embêter avec ça.

Si je comprends bien votre souhait, vous ne voulez pas obliger les utilisateurs de votre dll à utiliser le même compilateur que vous.

L'utilisation de wrappers serait idéales pour vous et j'insiste, cela n'implique qu'une recompilation des clients de l'API. Il n'y aurait aucune modifications dans le code client.

Avant :
dans le .h de l'API

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TOTODLL std::string getName();

Après :
dans le .h de l'API (wrapper à l'arrache)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
TOTODLL size_t _getName(char *buf,size_t taille)
...
std::string getName(){char buffer[MAX_NAME_LEN]; getName(buffer,MAX_NAME_LEN); return string(buffer);}

Mais pour le client, c'est toujours

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

string name = getName()

Pour la partie implémentation de l'API, vous pouvez utiliser le même stratagème qui consiste à déclarer dans un .h, inclus si "WIN32_DLL" est définie (ou un autre define plus précis), les fonctions qui passeront de getName à _getName.

Il vous reste donc :
soit à vérifier toutes les options de compilations et d'édition de lien et rendre vos environnements extrêmement strictes et rigides.
soit à implémenter des wrappers des deux côtés avec un travail qui sera très simple avec les strings mais nettement plus complexe avec les maps.

Je voudrais juste dire qu'une architecture à plugIn n'est pas si triviale que cela en à l'air et que l'approche avec wrapping n'est pas une rustine à un problème mais une méthode conventionnelle.