Discussion :

[r0d]

Bonjour,

je travaille sur un projet dont l'architecture est la suivante:
- un gros programme en c++ natif compil� sous forme de lib statique
- un wrapper c++/cli qui wrappe une classe et quelques fonction membre d'une classe de la lib c++
- un programme de test en c# qui utilise le wrapper c++/cli

le probl�me c'est que ce projet a �t� fait � l'aide de la technique du "doigt mouill�" (voyons vois si je modifie cette option ce que �a donne) et ce wrapper tombe en marche parfois, mais sur la plupart des plateformes, il crashe brutalement.

J'ai donc tout repris, unifi� les options de compilations (plateforme, configuration, charset, framework, ...). La dll en c++ natif semble nickel car je l'ai test� � l'aide d'un ex�cutable en c++ natif et �a marche parfaitement.

Mais par contre je rencontre d'�tranges probl�mes avec le wrapper c++/cli. Le code compile, mais �a plante � l'ex�cution, avant d'entrer dans le main() du test en c#. Le message d'erreur est le suivant:

First-chance exception at 0x000007fefd92bccd in rankManagedDllTest.exe: Microsoft C++ exception: EEFileLoadException * __ptr64 at memory location 0x0045c5f8..
First-chance exception at 0x7741ce3b in rankManagedDllTest.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
First-chance exception at 0x7741ce3b in rankManagedDllTest.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
First-chance exception at 0x7741ce3b in rankManagedDllTest.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
An unhandled exception of type 'System.AccessViolationException' occurred in Unknown Module.

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Un point qui m'attire l'attention c'est que le wrapper en c++/cli ne fait que 4Mo, alors que la lib en c++ natif fait de l'ordre de 100Mo. Or si c'est une lib statique, son assembly devrait �tre inclu dans la dll c++/cli, non?
Visiblement, le probl�me c'est qu'il ne parvient pas � loader la lib c++ dans l'executable c#, mais pourquoi?

Je me suis assur� que tous les binaires et les pdb soient bien g�n�r�s dans le m�me folder, mais �a ne change rien.

Je ne suis pas tr�s � l'aise avec le c++/cli, donc toute piste, remarque, conseil est le bienvenu.

[r0d]

Il y a quelque chose que je ne comprend pas dans ce projet, c'est que la lib en c++ ne link absolument rien. Je veux dire, dans options du projet -> librarian -> additional dependencies, il n'y a rien. Toutes les libs (xerces, etc.) utilis�es par la lib c++ sont link�es dans le wrapper C++/cli, alors qu'elles sont bien utilis�es dans le code de la lib c++. �trange non?

[M�dinoc]

J'ai du mal � voir comment une lib statique peut faire 100Mo sauf si elle est compil�e en /LTCG (Link-Time Code Generation). Auquel cas, je dirais qu'il est normal que le wrapper C++/CLI occupe moins de place.

Ensuite, que fait ton wrapper au sujet des exceptions C++? Je ne sais plus comment /clr et /EH sont cens� interagir. En tout cas, le debug du plantage montre un probl�me dans le traitement de la EEFileLoadException, qu'il soit � bas niveau ou dans ton code.

Peut-�tre devrais-tu r�gler ton debugger pour interrompte l'ex�cution au moment o� la EEFileLoadException est lanc�e, pour savoir � quoi elle est due. Bien s�r, �a ne traitera qu'un seul des deux probl�mes, mais ce sera d�j� �a.

[r0d]

J'ai du mal � voir comment une lib statique peut faire 100Mo sauf si elle est compil�e en /LTCG (Link-Time Code Generation). Auquel cas, je dirais qu'il est normal que le wrapper C++/CLI occupe moins de place.

Ben non, ce n'est pas compil� en /LTCG. En debug, la lib c++ fait m�me plus de 160Mo, c'est ahurissant! Elle inclus plusieurs libs externe en statique (dont xerces), ceci explique peut-�tre cela?

Ensuite, que fait ton wrapper au sujet des exceptions C++? Je ne sais plus comment /clr et /EH sont cens� interagir. En tout cas, le debug du plantage montre un probl�me dans le traitement de la EEFileLoadException, qu'il soit � bas niveau ou dans ton code.

Je ne trouve rien dans les options du wrapper concernant la gestion des exceptions :s

Peut-�tre devrais-tu r�gler ton debugger pour interrompte l'ex�cution au moment o� la EEFileLoadException est lanc�e, pour savoir � quoi elle est due. Bien s�r, �a ne traitera qu'un seul des deux probl�mes, mais ce sera d�j� �a.

Je ne comprend pas ce que tu veux dire; et je ne sais pas ce qu'est la EEFileLoadException. Comme je disais, �a plante avant m�me d'entrer dans le main(), donc je ne vois pas comment "r�gler le debugger" pour choper cette exception

[M�dinoc]

1. Une lib statique n'inclut pas d'autres libs statiques, donc �a ne doit pas �tre �a...
2. Project Properties -> C/C++ -> Code Generation -> Enable C++ Exceptions
3. Debug -> Exceptions... -> Cocher "C++ Exceptions", "Win32 Exceptions" et "Common Language Runtime Exceptions".

[r0d]

rha, je ne m'en sort pas avec cette histoire...
Alors j'ai tout nettoy�, maintenant ma dll ne fait "plus que" 20Mo. J'ai tout recompil� en x64 MDd, juusqu'� la moindre d�pendance (xerces, boost, mkl...). J'ai fait en sorte que tous binaires soient g�n�r�s au m�me endroit (comme �a pas de risque de me tromper de dll ou quoi).

Ma lib fonctionne toujours en natif, mais une fois wrapp�e, j'ai toujours un crash avant l'entr�e dans le main. Le message d'erreur n'est plus exactement le m�me, maintenant j'ai �a:

A first chance exception of type 'System.AccessViolationException' occurred in Microsoft.VisualStudio.HostingProcess.Utilities.dll

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

J'ai bien activ� toutes les exceptions, mais �a ne change rien. Il y a le m�me probl�me en debug et en release, que je lance le programme depuis visual (F5) ou � l'ext�rieur de visual (cmd).
Le comportement ne change pas non plus que je coche ou non l'option "enable the visual studio hosting process".

La pile d'appel:

[M�dinoc]

Merde, l�, je ne vois pas trop comment t'aider.

[themadmax]

En VS2008 il faut cocher dans Les prop. de ton application > Debug > Enable umanaged code debugging.
Lance ton programme avec F11, et regarde ou sa plante...
Sinon l'outils depends parfois peut �tre utile pour v�rifier les d�pendances manquantes.

[moldavi]

Bonjour.

Est-ce qu'un simple wrapper et une librairie tout basique �a plante aussi.

Si la r�ponse est non, proc�der par �limination. Partir d'un projet basique qui fonctionne, puis ajouter les biblioth�ques une � une, jusqu'� trouver celle qui pose probl�me.

[r0d]

Yep, excellente id�e. Je n'avais pas pens� � proc�der dans ce sens
Bon l� je suis sur autre chose je n'ai vraiment pas le temps de m'occuper de �a, mais j'y reviendrai dans quelques jours.