portabilité d'une dll

**seiryujay** · 23/11/2006, 11h42

Ben en fait, j'avais mis de fprintf dans la méthode qui crashe.
Mais on ne rentrait dans aucun. Donc en gros, soit il ne rentrait pas dans la méthode, soit l'erreur vient de l'une de ces lignes :

Code :

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

1
2
3
4
5
6
 
try {
	// Initialisation du fichier contenant les infos de test...
	FILE * fic;
	// Remise à zéro du fichier 
	fic = fopen("C:/MyLogFile.txt", "w+");

Je pensais que comme la méthode crashait le fichier n'était pas bien mis à jour, mais le fait que la femeture de la fenêtre entraîne aussi un crash alors que cette opération ne fait pas du tout appel à la dll m'intrigue énormément.

C'est vraiment frustrant comme erreur parce que je ne sais pas du tout où chercher...

**farscape** · 23/11/2006, 11h51

effectivement ,
ton contexte java est propre sous 2000 ? identique à celui sous xp ?
parce que si quand tu sors du programme ça crash sans appeller de fonctions, j'aurais tendance a dire que la dll n'y est pour rien dans l'histoire ...
verifie aussi tes ressources systemes : assez de mémoire ?

**seiryujay** · 23/11/2006, 12h00

Ouais, l'environnement Java est fourni avec mon appli pour être sûr qu'on ne rencontre pas de problème.

Par contre effectivement, mon appli peut-être très groumande en mémoire. Mais ça pourrait entraîner ce genre de message?
Je pensais qu'on aurait un autre type d'erreur style OutOfMemory.
Je vais essayer de voir si ça fonctionne sur un autre système. Ca me rassurerait...

Je te tiens au courant.
Merci pour tout en tout cas!

**seiryujay** · 23/11/2006, 12h13

Bon ben c'est pareil...
Le second système sur lequel j'ai testé mon appli est beaucoup plus performant que le premier, et il l'est suffisamment pour supporter les traitements réalisés.
Donc ça ne vient pas de là.

Je ne comprends vraiment pas...

**seiryujay** · 24/11/2006, 11h21

Pourquoi ça ne marcherait pas avec Windows 2000 alors que ça marche avec Windows XP???
Je déteste ces problèmes de compatibilité...
Je vais essayer d'installer Visual Studio 6 sur un poste Windows 2000 et compiler le projet directement sur ce poste, on verra ce que ça donne...

**farscape** · 24/11/2006, 11h39

d'apres les précédents post ,si la dll n'est pas du tout sollicitée et si ça crash en fermant le programme, elle est hors de cause.
tu es sur de ce point ?
il peut y avoir d'autres problémes concernant l'occupation GDI.
ton application consomme beaucoup d'objets GDI ?
à vérifier dans le gestionnaire de taches (en personnalisant l'affichage).
j'ai déja eu un probleme de cette nature avec mes programmes le nombre d'objets GDI par systeme variait entre win95 NT4 et XP.
et suivant le systéme le moins tolerant je plantais...
sachant qu'il y a une limite d'objet GDI par session, cette valeur est peut etre differente entre win2000 et winxp.
à verifier ...
http://msdn2.microsoft.com/en-gb/library/ms724291.aspx

**seiryujay** · 24/11/2006, 12h46

Bon, je progresse...
J'ai réussi utiliser ma dll correctement, mais eulement une fois que j'ai ouvert avec mon appli un auter type de fichier qui n'utilise pas du tout ma dll, mais ouvre aussi la fenêtre d'arborescence.
J'ai aussi réussi à générer un rapport d'erreur java qui m'indique bien que le crash se produit lorsque j'appelle un de mes méthodes natives (autrement dit, une des méthodes de ma dll).

Sur ce nouveau poste, j'obtiens le message d'erreur :
"L'instruction "0x..." emploie l'adresse mémoire "0x00000000". La mémoire ne peut pas être "read"."
C'est un problème que j'avais déjà rencontré sous XP, mais qui est résolu maintenant.
Reste à savoir pourquoi il apparaît sous 2000...

PS : la limite des objets GDI est fixée ) 2710 pour XP et 2000. Mais j'ai testé en mettant 65000 et ça crashe aussi.

**farscape** · 24/11/2006, 12h54

bon alors on revient à la case départ .
dans ton cas ton code accède à une adresse Nul ,en gros un pointeur Nul
il te reste a savoir pourquoi il est nul,
quelles sont les conditions pour qu'il soit initialisé etc...

**seiryujay** · 24/11/2006, 13h09

Je vais chercher, mais pourquoi est-ce que j'aurai un pointeur NULL sous 2000 et pas sous XP???
C'est sioux cette histoire...

**farscape** · 24/11/2006, 13h15

ça peut etre lié à un ordre d'initialisation ....
si ton pointeur est alloué sur un message par exemple.

**seiryujay** · 24/11/2006, 13h39

Bon ok, source du problème identifiée...
C'est une histoire de threads...

J'ai déjà galéré avec ça avant.
En fait, ma dll interface appelle la dll qu'on m'a fournit afin de récupérer des données dans certains fichiers. Pour cela on utilise m_pDataFile qui est un pointeur vers l'objet permettant d'accéder aux données du fichier.

J'avais codé une première méthode de relecture qui laissé ce lien vers le fichier ouvert tant que je ne voulais pas charger un autre fichier, de manière à ne pas avoir à recharger cet objet à chaque fois que je voulais récupérer certaines données du fichier.
Malheureusement, dans mon appli Java, j'utilisais des threads de manière à pouvoir afficher une progressbar et de manière à ne pas figer mon IHM pendant la récupération des données.

Manque de bol, l'utilisation de threads pouvaient entraîner des crash comme celui qu'on observe actuellement si le m_pDataFile restait ouvert.

Du coup, j'ai créé une nouvelle méthode de relecture qui ferme l'accés au fichier (via le m_pDataFile) dès qu'on a récupéré le groupe d'infos dont on a besoin et le réouvre à chaque fois qu'on veut récupérer un nouveau groupe de données. (je ne sais pas si je suis clair)
Cette solution fontionne sous XP même avec l'utilisation de threads, mais crashe sous 2000.
Par contre, elle fonctionne sous 2000 si on vire l'utilisation des threads.

Donc en gros y'a un problème d'accés au fichier via la dll fournie quand on utilise des threads.
Les threads étant gérés par Java et la relecture du fichier étant gérée par JNI, ma dll interface et la dll fournie, je ne sais pas par où commencer.

Je ne suis pas un pro du C++ (loin de là), donc y-a-t'il quelque chose à faire dans ma dll interface pour que l'utilisation de threads en Java ne pose pas de problème?
Ou alors cette gestion doit-elle être faite dans la dll qu'on me fournit?
Ou n'y-a-t'il aucun moyen d'utiliser les threads Java dans ce cas là? (je devrais peut-être créer un nouveau topic sur le forum Java pour ça...)

Au cas où ça aiderait voici le bout de code permettant d'ouvrir un fichier via ma dll interface :

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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
 
// Ouverture de la communication avec le fichier...
JNIEXPORT jboolean JNICALL Java_jni_LibraryInterface_openFile
  (JNIEnv * env, jobject obj, jstring path)
{
	try {
		// Initialisation du fichier contenant les infos de test...
		FILE * fic;
		// Remise à zéro du fichier 
		fic = fopen("C:/MyLogFile.txt", "a+");
		fprintf(fic, "OpenFile()...\n");
 
 
		//NOTE: It you are in a MFC project, Do not forget to Add ::CoInitialize() like in method InitInstance() 
		//before calling CreateInstance, if you don't put this call, CreateInstance will fail!!!
		if (m_pDataFile == NULL ) {
			fprintf(fic, "m_pDataFile == NULL\n");
			// Smart pointer used to access the COM object.
			HRESULT hr = m_pDataFile.CreateInstance( __uuidof(DataFile::DataFile) );
			if(FAILED(hr))
			{
				fprintf(fic, "m_pDataFile.CreateInstance() failed...\n");
				throw(hr);
			}
 
			// Unlock security with the IDataFileEx::InternalUse() method
			DataFile::IDataFileExPtr pDataFileEx = m_pDataFile;
			pDataFileEx->InternalUse( _bstr_t("Unlock") );
		}
 
 
		// on remplace les accents...
		char * pathConverted = JNU_GetStringNativeChars(env, path);
 
		if (pathConverted == NULL) {
			printf("OpenFile () => pathConverted == NULL\n");
			fprintf(fic, "OpenFile () => pathConverted == NULL\n");
		}
		else {
			fprintf(fic, "En attente de l'OpenFile()...\n");
			m_pDataFile->OpenFile((_bstr_t)pathConverted);
			fprintf(fic, "m_pDataFile->OpenFile() ok...\n");
		}
 
		// Fermeture du fichier 
		fclose(fic);
 
		return TRUE;
	}
	catch(_com_error &e)
	{
		DisplayErrorDescription(e);
		return FALSE;
	}
}
 
 
//Fermeture de la communication avec le fichier.
JNIEXPORT jboolean JNICALL Java_jni_LibraryInterface_closeFile
  (JNIEnv * env, jobject)
{
	// Initialisation du fichier contenant les infos de test...
	FILE * fic;
	fic = fopen("C:/MyLogFile.txt", "a+");
	// Remise à zéro du fichier 
	fprintf(fic, "CloseFile() en cours...\n");
 
 
	if(m_pDataFile != NULL) {
		m_pDataFile->CloseFile();
		fprintf(fic, "m_pDataFile->CloseFile()...\n");
		m_pDataFile = NULL;
		fprintf(fic, "m_pDataFile = NULL...\n");
	}
 
	m_pChannel = NULL;
	m_pBeam = NULL;
	m_pGate = NULL;
	m_pDataGroup = NULL;
 
	fprintf(fic, "CloseFile() fait...\n");
	// Fermeture du fichier 
	fclose(fic);
 
	return TRUE;
}

En gros, ce serait la fermeture du m_pDataFile qui ne se ferait pas de la bonne manière selon moi et du coup, quand on essaie de réaccéder au fichier (=> réinitialisation du m_pDataFile), on rencontre un problème qui fait tout crasher...

Mon code vous semble-t-il incomplet pour la prise en charge des threads ou le problème viendrait-il de la dll qu'on me fournit? (je sais, c'est question délicate...

)

PS : suite à la première ouverture de fichier tous les fprintf sont présents dans le logfile...

**farscape** · 24/11/2006, 13h50

ça serait pas un probleme de synchro au niveau de tes threads ?
que se passe t'il si apres l'ouverture fichier par un thread la fonction close est appelée par un autre, à mon avis ça crash...

**seiryujay** · 24/11/2006, 14h33

Envoyé par farscape

ça serait pas un probleme de synchro au niveau de tes threads ?

Possible, mais comment le savoir? Et comment y remédier?

Envoyé par farscape

que se passe t'il si apres l'ouverture fichier par un thread la fonction close est appelée par un autre, à mon avis ça crash...

Euh, je sais pas trop...
Chez moi, tout se fait dans le même thread normalement :
1) y'a un thread qui affiche l'arborescence du fichier => appel à openFile(), à des méthodes de récupération d'infos sur le fichier et à closeFile() => OK pas de problème.
2) quand on double-clique sur un des noeuds (on est toujours dans le 1er thread, mais la méthode closeFile() a été appelée), on récupère dans le fichier les données associées au noeud sélectionné => appel à openFile() (pour recréer le lien vers le fichier qui a été détruit suite à l'appel de la méthode closeFile()), à une méthode de récupération de données, et à closeFile(). => Crash
Dans ce cas, on est dans un thread à l'intérieur d'un autre thread, ce qui peut peut-être poser problème.

Mais si on ne fait qu'afficher l'arborescence et la fermer derrière, on a aussi un crash alors qu'on n'accède pas à la dll.

C'est pour ça que j'ai du mal à comprendre...

portabilité d'une dll

MFC

Discussions similaires

Partager

Partager