Discussion :

[yildiz-online]

Bonjour a tous,

Dans le cadre d'un frontend retro, je dois charger et décharger des lib dynamiques pour changer d'émulateur.
Tout fonctionne très bien hormis un irréductible MAME (émulateur arcade) qui pour une raison qui m'échappe refuse de se décharger.

Pour éviter de mettre en cause mon code j'ai reproduit un exemple minimal, a savoir, charger, décharger, attendre 30sec(le temps de vérif. dans process explorer) et vous vous en doutez, il est toujours la, tapis dans l'obscurité.



Le code de test:

Code :

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

1
2
3
4
5
6
 
//Code java qui appelle ma lib, dans laquelle se trouve le code plus bas
System.load("D:\\dev\\prj\\retro-player-emulator-libretro\\bin/libpxl.dll");
LibRetro l = new LibRetro(Path.of("D:\\dev\\prj\\retro-player/data/local/emulators/libretro"));
l.loadCore(LibRetroCore.MAME);
Thread.sleep(30000);

Code :

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

1
2
3
4
5
6
7
8
 
PXLEXPORT void loadCore(const char* libPath) {
   auto hndl = LoadLibraryA(libPath);
   auto r = FreeLibrary(hndl);
   if(r) {
       pxlLogInfo("UNLOAD LIB");
   }
}

Si quelqu'un a une idée de pourquoi cette lib(libretro_mame.dll) est capricieuse alors que les autres, aucun soucis

[skeud]

J'ai eu un cas similaire, et c'était du fait que ma dll ne libérait pas des ressources qu'elle avait allouée, du coup elle ne se déchargeait pas de la mémoire. C'est une dll à toi ou tu n'as pas la main sur le code?

[yildiz-online]

C'est une lib externe, j'ai juste la main sur celle qui la charge, utilise et la decharge(enfin essaie de la decharger du moins)

Meme en faisant un load puis free immediatement, des resources seraient allouee selon toi? (sachant que je n'ai pas trouve de maindll)

[Mat.M]

Si quelqu'un a une idée de pourquoi cette lib(libretro_mame.dll) est capricieuse alors que les autres, aucun soucis

tout est expliqué dans le MSDN.
LoadLibrary en interne augmente des références et au besoin charge la dll concernée via le Kernel
FreelLibrary ne fait que décrémenter les références.
Si référence=0 alors la dll est déchargée de la mémoire.
Tout simplement parce que la dll peut être appelée par d'autres programmes donc chercher pourquoi la dll n'est pas déréférencée ailleurs avec un autre FreeLibrary
Ensuite il vaut mieux utiliser LoadLibraryEx.

[yildiz-online]

J'ai bien compris le concept de reference counting pour le dechargement, et justement c'est bien ma question

1) Mon application est la seule a utiliser cette lib.
2) Process explorer n'a aucune trace d'une autre instance.
3) Les librairies des autres emus n'ont pas ce probleme.

Mon exemple simple montre bien un load/free immediat et pourtant la lib reste chargee jusqu'a ce l'application appelante termine

Donc je seche

[skeud]

Tu as vérifier que tu n'as pas un thread qui appelle cette lib? Genre un thread créé par la lib au chargement (oui c'est un peu tordu comme idée, mais sait-on jamais)

[yildiz-online]

Oui c'est une possibilite qu'on m ' aussi soumise sur un autre forum, je n'ai pas vérifié. la base de code étant assez maousse, faudrait trop creuser.

Je vais faire 2 autres tests demain: sous linux(enfin WSL), et un test avec juste le load et le free mais aussi le init/deinit entre les 2

[skeud]

Après tu as aussi certaine librairie qui ont des variables globales, si c'est le cas, malheureusement tu ne pourras rien faire

[yildiz-online]

Après tu as aussi certaine librairie qui ont des variables globales, si c'est le cas, malheureusement tu ne pourras rien faire

J'ai teste sous linux et tout fonctionne parfaitement, la librairie est bien dechargee une fois le jeu quitte, donc c'est un probleme uniquement lie a windows, on peut donc je pense ecarter cette piste

[LittleWhite]

Bonjour,

Est-ce que le problème se produit pour toutes les bibliothèques que vous chargées/déchargées?
Après, je pense que ce n'est pas un problème, dans le sens, faites confiance au système. Il a ses raisons . Si vous rechargez la bibliothèque juste après, elle ne sera pas instanciée deux fois, donc pas d'augmentation de mémoire.
Aussi, avez vous vérifié s'il y avait une erreur (je doute qu'il y en ai):

If the function fails, the return value is zero. To get extended error information, call the GetLastError function.

[yildiz-online]

Bonjour,

Est-ce que le problème se produit pour toutes les bibliothèques que vous chargées/déchargées?

Salut,
Uniquement pour mame windows, les autres(snes9x, nestopia, gdx, mame linux,...) le dechargement est bien effectif.
La dll mame fait 300 mo

Après, je pense que ce n'est pas un problème, dans le sens, faites confiance au système. Il a ses raisons . Si vous rechargez la bibliothèque juste après, elle ne sera pas instanciée deux fois, donc pas d'augmentation de mémoire.

Mon systeme n'a pas ete concu dans cette optique et relancer l'emu provoque un blocage

Aussi, avez vous vérifié s'il y avait une erreur (je doute qu'il y en ai):

Oui j'ai verifie, le dechargement de mame me dit bien ok, FreeLibrary me retourne un non 0

[LittleWhite]

Rapportez le bogue à l'équipe de MAME, peut être ils sauront .

[yildiz-online]

Le problème est finalement résolu, en déchargeant la librairie MAME ainsi que la librairie appelante, ce qui est désormais possible avec java 19 via les MemorySession de la JEP 424.