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.