Discussion :

[atoutsweb]

Bonjour,

J'utilise une librairie (.lib) qui semble avoir été développée pour une console.
Lorsque j'appelle certaines fonctions, si certains des paramètres sont faux, la librairie réalise une sortie console puis ferme la console. Le problème c'est que j'utilise cette librairie depuis une application MFC et que lorqu'une erreur se produit, je suis incapable de récupérer cette sortie et de plus mon application se met en erreur car la mémoire est libérée.

Quelle serait la solution ? L'ouvrir dans un autre process ?

Merci

[bacelar]

C'est normale qu'une librairie qui est en train de partir en vrille lève une exception pour permettre une correction rapide via des dumps.

Votre application ne doit pas tenter de rattraper l'erreur, votre espace mémoire est compromis, il ne faut que faire les traitement de replis dans les sections _finally du code.

Si le problème est un paramètre erroné par exemple, la documentation de la librairie doit indiquer le type d'exception et vous pourrez "catcher" les exceptions que vous savez gérer.

Si les dumps montrent que la librairie par en sucette "sauvagement", ils permettrons aux mainteneurs de la lib de corriger le tir.

Si vous n'êtes pas en contact avec les mainteneurs et que la librairie est buggué, isolez-là dans un process indépendant qui crèvera en même temps de le bug de la librairie, mais votre espace mémoire ne sera pas corrompu.

[atoutsweb]

En fait elle ne lève pas volontairement d'exception, c'est un memory access violation qui se produit lors de l'appel à la fonction de la lib qui appelle exit. Il n'y a donc aucune remontée d'exception que je puisse récupérer dans un bloc catch.

Voici la pile simplifiée

LIB!InternalDLLMain ==> MEMORY ACCESS VIOLATION
LIB!DllMainCRTStartup
NTDLL!??
KERNEL!??
LIB!DOEXIT(status=1,quick=0,retcaller=0)
LIB!EXIT(1)
LIB::MAFONCTION()
MFC::MAIN()

[bacelar]

"memory access violation", c'est du jardinage en mémoire (si pas first chance).
Ne surtout pas tenter de survivre à ce genre de truc.
Votre mémoire est peut-être entièrement corrompu.

Utilisez une version debug avec les informations de debugging (le fichier pdb associé) et activer le debuggeur de VS pour qu'il arrête le debuguee dés le lancement de ce type d'exception.

Vous aurez le motif exact de l'erreur et vous pourrez savoir si le problème est chez vous ou chez eux.

[atoutsweb]

Bonjour,

Je suis passé plus en détail dans le débogage et j'ai remarqué que la fonction InternalDllMain est appelée 2 fois pour fermer l'application.

La première fois, ces lignes s'exécutent correctement :

CWinApp* pApp = AfxGetApp();
if (pApp != NULL)
pApp->ExitInstance();

La seconde fois, pApp n'est pas nul mais le pointeur est invalide ce qui provoque l'erreur.

La question est donc : pourquoi la fonction est t'elle rappelée ? En tous cas elle ne l'est pas par mon code, peut être pas le destructeur de CWinApp ?.

En tous cas, même si je comprends un jour ce phénomène, cela ne résoudra pas mon problème car je ne veux pas que le process soit fermé. J'ai donc créé une app console que je lance avec un ShellExecuteEx() et je récupère le return code.

[bacelar]

Attention, vous avez dans votre programme autant de InternalDllMain différent que de module binaires (exe et dll) qui utilisent les MFC.

Vous semblez avoir un problème au déchargement de dll ou de l'exécutable, c'est souvent la cas quand on ne configure pas correctement les différents projets et en utilisant les mauvaises versions des librairies.

Moi, avant de dire que c'est la librairie qui déconne, je vérifierais que je n'ai pas merdé avec les pré-requis d'utilisation de celle-ci.