Runtime C++ / VS 2008

Version imprimable

02/06/2008, 17h28
sandul

Runtime C++ / VS 2008

Bonjour,

Je viens du monde Java et mes connaissances C++ sont limit�es: ce que j'avais appris en fac, loooong time ago + quelques projets de petite envergure...

J'h�rite donc d'un projet important C++ (une dll) et j'acc�de � cette dll depuis Java (via JNI). Le projet C++ initial a �t� cr�� sous VS 6 et je l'ai port� sous VS 2008. Jusque l� tout baigne.

En for�ant une exception C++ � des fins de test, je retrouve dans le dump Java ceci:
...
0x00400000 - 0x00423000 C:\bin\java\bin\java.exe
0x7c920000 - 0x7c9e6000 C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c912000 C:\WINDOWS\system32\kernel32.dll
0x77d70000 - 0x77e1d000 C:\WINDOWS\system32\ADVAPI32.dll
0x77c20000 - 0x77cbf000 C:\WINDOWS\system32\RPCRT4.dll
0x76f00000 - 0x76f13000 C:\WINDOWS\system32\Secur32.dll
0x7c340000 - 0x7c396000 C:\bin\java\jre\bin\msvcr71.dll
0x6d870000 - 0x6dac0000 C:\bin\java\jre\bin\client\jvm.dll
0x77f30000 - 0x77fc1000 C:\WINDOWS\system32\USER32.dll
0x77bd0000 - 0x77c18000 C:\WINDOWS\system32\GDI32.dll
0x76a50000 - 0x76a7f000 C:\WINDOWS\system32\WINMM.dll
0x6d320000 - 0x6d328000 C:\bin\java\jre\bin\hpi.dll
0x76b20000 - 0x76b2b000 C:\WINDOWS\system32\PSAPI.DLL
0x6d820000 - 0x6d82c000 C:\bin\java\jre\bin\verify.dll
0x6d3c0000 - 0x6d3df000 C:\bin\java\jre\bin\java.dll
0x6d860000 - 0x6d86f000 C:\bin\java\jre\bin\zip.dll
0x10000000 - 0x10430000 C:\tmp\trial\MyDLL.dll
0x71a80000 - 0x71a8a000 C:\WINDOWS\system32\WSOCK32.dll
0x71ad0000 - 0x71ae7000 C:\WINDOWS\system32\WS2_32.dll
0x77b70000 - 0x77bca000 C:\WINDOWS\system32\msvcrt.dll
0x71ac0000 - 0x71ac8000 C:\WINDOWS\system32\WS2HELP.dll
0x775c0000 - 0x7764b000 C:\WINDOWS\system32\OLEAUT32.dll
0x77480000 - 0x775b9000 C:\WINDOWS\system32\ole32.dll
0x78480000 - 0x7850d000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375\MSVCP90.dll
0x78520000 - 0x785c3000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375\MSVCR90.dll
....

Ce sont surtout les deux derni�res DLL qui m'inqui�tent, car situ�es dans WinSxs. La trace d'erreur est obtenue sur une machine 2K3 server sur laquelle j'avais recompil� le projet C++ et les deux DLL existent bel et bien dans WinSxS sur cette machine. Mais j'ai fait un test simple: j'ai copi� dans le path les 2 DLL runtime et par la suite j'ai mis � la Corbeille le contenu du r�pertoire C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375\ . A l'ex�cution, il y a un message d'erreur, comme quoi il ne trouve pas les biblioth�ques n�cessaires.

Deux questions:

1. Comment puis-je me d�barasser du nom EN DUR dans ma DLL (� savoir, C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375\MSVCP90.dll) et pouvoir mettre une copie de MSVCP90.dll dans le path (� c�t� de ma DLL que j'appelle depuis Java) ?

2. J'ai �galement constat� que � chaque fois que je refais un build de la DLL sous C++, VS 2008 me cr�e un nouveau r�pertoire sous C:\WINDOWS\WinSxS\ avec les deux DLL dedans (en fait il y en a une 3�me, toujours un runtime). Y a-t-il un moyen d'emp�cher ce fonctionnement (car avec mon exp�rience C++ je vais compiler des centaines de fois et je pense � l'espace disque :-D :-D)

D'avance un grand merci.
02/06/2008, 18h00
M�dinoc
1. Le chemin n'est pas cod� en dur. Les DLLs font partie d'un Assembly identifi� par ses nom, processeur, version et hash.
  Si tu veux fournir les DLL � c�t� du programme, tu dois copier l'assembly complet, les DLLs et leur manifeste:
  - MSVCR90.DLL
  - MSVCP90.DLL
  - MSVCM90.DLL
  - Microsoft.VC90.CRT.manifest
2. Je n'ai jamais eu ce comportement avec VS 2005: Chez moi, il y a juste un certain nombre de dossiers Microsoft.VC80.CRT, et ce nombre ne varie pas avec les recompilations.
  Je ne sais pas pourquoi ton 2008 fait �a (ou a l'air de faire �a), mais WinSxS �tant le Global Assembly Cache, il a peut-�tre une limite de taille de toute fa�on...
02/06/2008, 18h23
sandul

Merci pour la r�ponse.
Tu dis: "Le chemin n'est pas cod� en dur", mais comment sait-il chercher dans le r�pertoire C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375? Il n'est pas dans le path.

J'ai essay� avec ce que tu proposes (fichier manifest):
a- j'en ai trouv� un dans c:\program files\microsoft visual studio 9.0\vc\redist\x86\Microsoft.VC90.CRT et
b- je l'ai recopi� � c�t� des 3 dll runtime et de ma dll.

Le dump reste le m�me (� savoir, toujours les DLL dans le r�pertoire XsX qui sont charg�es et pas leurs copies). J'ai �galement essay� de modifier le nom du manifest en le rebaptisant MyDLL.manifest (pour avoir le m�me nom que mon DLL, il me semble avoir lu ceci une fois, mais je crois que cela �tait pour les .exe) avec le m�me r�sultat.

Faut-il bidouiller les options Manifest Tool dans les propri�t�s du projet de cr�ation de DLL?

Encore merci
02/06/2008, 18h34
sandul

En recherchant un peu (ex http://cpp.developpez.com/faq/vc/ind...VC2005VCRedist) je retrouve

"Si on ne veut pas distribuer de DLL ,il faudra lier statiquement les MFC et s�lectionner dans l'onglet C++ / option g�n�ration de code / biblioth�que runtime :Multithread (/MT)".

Le souci, c'est que le projet dll s'appuie sur un autre projet pour cr�er un .lib (option de compilation: /MD) qui � son tour fait appel � des composants achet�s sans code source mais complil�s � leur tour avec VS 2008 et avec la m�me option (/MD). Je crois que l'option /MT n'est pas un choix valide dans mon cas, non?
02/06/2008, 19h58
farscape

salut,
il ne vaut mieux pas ...

Citation:

Envoy� par faQ

Si on ne veut pas distribuer de DLL ,il faudra lier statiquement les MFC et s�lectionner dans l'onglet C++ / option g�n�ration de code / biblioth�que runtime :Multithread (/MT)
N�anmoins il faudra veiller � ne pas m�langer les modes de fonctionnement avec la CRT en Multithread DLL et statique, pour �viter les probl�mes sur les lib�rations d'objets entre modules ou partage de ressources fichiers.
02/06/2008, 21h48
M�dinoc

Citation:

Envoy� par sandul

Merci pour la r�ponse.
Tu dis: "Le chemin n'est pas cod� en dur", mais comment sait-il chercher dans le r�pertoire C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375? Il n'est pas dans le path.

Comme je l'ai d�j� dit, WinSxS est un dossier sp�cial (le Global Assembly Cache). Windows sait naturellement o� il se trouve, donc si un assembly est dans le GAC, Windows le trouvera.

Citation:

J'ai essay� avec ce que tu proposes (fichier manifest):
a- j'en ai trouv� un dans c:\program files\microsoft visual studio 9.0\vc\redist\x86\Microsoft.VC90.CRT et
b- je l'ai recopi� � c�t� des 3 dll runtime et de ma dll.

Le dump reste le m�me (� savoir, toujours les DLL dans le r�pertoire XsX qui sont charg�es et pas leurs copies). J'ai �galement essay� de modifier le nom du manifest en le rebaptisant MyDLL.manifest (pour avoir le m�me nom que mon DLL, il me semble avoir lu ceci une fois, mais je crois que cela �tait pour les .exe) avec le m�me r�sultat.

Sur un PC o� le runtime est dans le GAC, c'est normal que Windows prenne celui du GAC puisse que c'est la m�me version. Par contre, un programme joint aux DLLs et au manifeste devrait fonctionner sur un poste o� le Paquetage Redistribuable de Visual 2008 n'est pas install�.
03/06/2008, 20h20
sandul

Merci beaucoup, M�dinoc. Effectivement, sur une autre machine �a marche avec les dll de runtime + le manifeste.

J'ai maintenant un autre souci:
Lorsque je dis "�a marche" cela signifie que le programme se lance, il y a le premier appel natif depuis Java, c�t� C++ je peux voir dans la console des messages qui m'appartiennent, mais �a plante vite-fait.

Sur la machine avec VS2008 �a plante aussi, mais autrement. Plus exactement, je n'ai pas r�ussi � avoir un plantage durant tout une batterie de tests (durant des heures). Les tests comportent la cr�ation d'un wrapper Java pour une classe C++ et beaucoup beaucoup d'appels natifs par la suite. Si je fais, � la fin, la destruction de l'objet (un delete() sur le wrapper) et je le recr�e durant le m�me jeu de tests j'arrive � un moment donn� � faire planter l'appli depuis la machine VS2008 aussi avec un siginfo d'essai de lecture d'une basse adresse (0x000000004). Cette machine plante donc aussi, mais elle est bien plus robuste que les autres machines (sans VS2008 install� ==> j'ai test� 3 autres machines et le r�sultat est le m�me, � savoir plantage IMMEDIAT sur le premier constructeur C++ apr�s l'�criture de quelques lignes de debug)

Il y a donc quelque chose qui cloche dans la partie C++, mais le souci est que les tests effectu�s uniquement � partir de C++ ne permettent pas de mettre en �vidence cette anomalie. Est-ce que vous avez une id�e concernant les possibilit�s d'isoler l'anomalie? Des outils existants? Ou n'importe quelle suggestion? Car passer au peigne fin le projet C++ (qui fait presque 2 Mo de code source + des biblioth�ques tierce dont je n'ai pas le code) est une option que j'ai d�j� �cart�e...

Encore un grand merci
03/06/2008, 22h57
M�dinoc

Je me demande si tu n'essaies pas de d�truire dans une DLL (voire l'exe de la JVM) un truc que tu as allou� dans une autre...