Discussion :

[greenzephyr]

Bonjour à tous !

J'ai un pb un peu chiant à debugger ...
Mon projet C# fait référence à une dll C++ CLI qui contient une classe que je nommerai ici Class1.

A chq fois, que mon application se ferme, j'ai une erreur de mémoire ("L' instruction à l'adresse XXX emploie l'adresse mémoire YYY. La mémoire ne peut pas être Read").

Pour faire un test j 'ai fait une Form avec juste un seul attribut (pour forcer le chargement de la dll):

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public partial class Form1 : Form
{
        private Class1 _obj = null;
 
        public Form1()
        {
            InitializeComponent();
        }
}

Et bien ca plante toujours. Il y a visiblement un pb avce le déchargement de la dll.
J'ai essayé les modifs suivantes dans mon code C++ CLI:
1°) #include <msclr\auto_handle.h>
2°) finalizer sur les classes

Rien à y faire.
De toute facon je ne crois pas que ce soit un pb de destructeur car je crée meme pas d'objet.

SVP, aidez-moi ... je desespère de trouver la raison de ce plantage.

Merci

[smyley]

Serai-t-il possible de voir ton code C++ ?

[greenzephyr]

Merci de ta réponse si rapide.
Plusieurs choses...

1°) En fait, je n'ai pas accès au code de la dll native en C++ (nommée Core.dll). Je dispose uniqutement de son lib, son h et la dll.

Son header:

Code :

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

1
2
3
4
5
//Core.h
 
#pragma once
 
extern "C" __declspec(dllexport) void InitAPI();

2°) Voici mon code C++ CLI (managé) pour wrapper la dll.

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
// Class1.h
 
#pragma once
#pragma comment (lib, "./Native/Core.lib")
 
#include "./Native/Core.h"
 
using namespace System;
 
#include <msclr\auto_handle.h> 
 
namespace Wrapper {
 
	public ref class Class1
	{
	public :
		Class1(){
		}
 
		Class1(){
		}
 
		!Class1() {
		}
 
		void InitNativeDll(){
			InitAPI();
		}
        };
}

3°) enfin mon utilisation dans C#

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 public partial class Form1 : Form
    {
        private Class1 _obj = null;
 
        public Form1()
        {
            InitializeComponent();
 
        }
 
    }

Tu vois , a priori pas de quoi décoiffer un boeuf !

Si j'enleve ma méthode InitNativeDll qui fait appel à InitAPI de ma dll native, ca ne plante pas. Je comprends vraiment pas...

[smyley]

Le problème doit forcément venir de la dll native.
- Par hasard, après l'appel à InitApi, ne faudrait-il pas appeller une autre fonction pour décharger ta dll ? ( genre un DeInitApi ? )
- Si tu utilise la dll à partir d'une appli en C++ purement natif, le problème existe-t-il ?
- Que fait la dll Core.dll ? elle ne modifie pas le comportement du programme ( je sais pas, en faisant des optimisations, de la gestion de mémoire, ou des trucs de oufs ) : en gros, si tu as accès à une quelconque documentation, est-il mentionné qu'elle peut se charger dans une application .NET ?

edit: il n'est pas nécéssaire de créer l'objet pour appeller la dll, dès que le framework va voir la référence à la dll native dans ta classes, je suppose qu'il va appeller DllMain dans la dll native, et cette fonction pourrai faire quelque chose de louche ...

[greenzephyr]

Je vais regarder pour tes questions mais ....
Ce qui m'étonne cc'est que j'ai un plantage à la sortie de l'appli. alors que je n'ai jamais instancié Class1, et encore moins appeler InitApi.

Je suis en train de me demander ...
si la dll native contient un main, celui est appelé au load de la dll?

[greenzephyr]

En plus, si je n'appelle pas InitApi, en quoi sa présence dans ma classe Class1 peut elle provoquer ce plantage ?

(c est flagrant, si je vire Initapi, ca roule ..)

[smyley]

Je suis en train de me demander ...
si la dll native contient un main, celui est appelé au load de la dll?

Oui, oui, j'ai édité mon post, mais un peut tard ...

[greenzephyr]

Ok je vais essayer de voir sir je peux avoir des infos sur le contenu du main et de InitApi.

N'empeche que je comprends toujours pas pourquoi mettre en commentaire InitApi dans InitNativeDll résout le bug.
A moins que la présence de InitApi oblige à charger d'autres dll mais ca je peux pas le voir....

[smyley]

N'empeche que je comprends toujours pas pourquoi mettre en commentaire InitApi dans InitNativeDll résout le bug.
A moins que la présence de InitApi oblige à charger d'autres dll mais ca je peux pas le voir....

Le pire c'est que je trouve celà logique
En effet, s'il n'y a aucune référence à la dll, il n'y a aucune raison de la charger et peut être même que le compilateur ne prend même pas peine de générer une référence ( que ce soit nativement dans la table import ou avec un PInvoke, j'ai jamais vraiment compris comment les import se passaient en C++/CLI ).
Par contre, s'il y a une référence :
- si la référence est purement managée, en .NET il n'y a pas d'initialisateurs globaux ( j'entend par là l'équivalent du main ) et le CLR ne charge la dll que lors de l'entrée dans la méthode qui appelle la dll.
- si la référence est native ( ta dll Core.dll ) alors le CLR se soucie d'initialiser la dll et appelle DllMain ... ce qui crash ton application ...

[ced600]

J'ai une idee qui a peu de chance de resoudre le problème, mais on ne sait jamais.
As tu deja essaye de faire reference à une autre DLL que core.dll.
Juste pour verifier que le problème n'intervient qu'avec cette dll et ne se fait pas avec d'autre.