Discussion :

[FM_UA]

Salutation

un petit problème douteux.
dans mon programme delphi j'utilise des DLL avec FastShareMem.
Jusque la, pas de problème.

L'une des DLL a besoin de WHTTP.dll
et c'est la que ca pose problème.
le chargement dynamique plante avec

Violation d'accès à l'adresse 009D7404. Lecture de l'adresse 009D7404

bon ok je test en statique : ca marche une fois et apres ca replante tout le temps...


Il faut savoir que le programme que je développe était a l'origine un gros CGI que j'ai découpé en DLL pour l'optimiser. Il utilise en dynamique WHTTP.dll mais bien sûr, lui n'a pas ce problème.

c'est pourquoi je me demande si le fait qu'une dll soit appelée par une autre puisse provoquer ce genre de violation d'accès ???

merci

[chaplin]

Dans la FAQ Fastmm, il est dit:

Q: How do I get my DLL and main application to share FastMM so I can safely pass long strings and dynamic arrays between them?
A: The easiest way is to define ShareMM, ShareMMIfLibrary and AttemptToUseSharedMM in FastMM4.pas and add FastMM4.pas to the top of the uses section of the .dpr for both the main application and the DLL.

De même pour FastShareMem:

The FastSharemem code comes into play only when each Delphi DLL or EXE is loaded into memory. After that, FastSharemem is no longer involved. Each memory allocation, in both EXE and DLL's, now work just as they do when there are no DLLs--unlike Sharemem/Borlndmm.dll, there is no "memory middleman". Your application functions exactly as it does when only a single .EXE is involved. This improves performance, and eliminates many bugs.

A priori, il s'agit de partager de la mémoire entre les exe et les dll faites en Delphi en utilisant ce méchanisme. Est ce que WHTTP.dll que tu appelles implémente aussi ce mécanisme ?

Disons qu'une raison majeure d'utiliser FastShareMem, c'est de partager un espace mémoire entre l'exe et les dlls.

[FM_UA]

j'utilise FastShareMem pour les autres DLL.
WHTTP.dll n'en a pas besoin, il demande des PChar

mais comme la DLL qui appelle WHTTP.dll utilise FastShareMem, peut être ya t'il un conflit.

[chaplin]

j'utilise FastShareMem pour les autres DLL.
WHTTP.dll n'en a pas besoin, il demande des PChar

mais comme la DLL qui appelle WHTTP.dll utilise FastShareMem, peut être ya t'il un conflit.

Mémoire partagé(exe&dlls)+ thread(WHTTP), est ce que ça fait bon ménage, c'était juste une réflexion, je sais pas si ça t'aidera. C'est le genre de casse tête dont personne ne voudrait avoir affaire .

A la limite, si tu mettrais ton code de la dll dans l'exe qui appelle WHTTP, qu'est ce que ça donne ?

[FM_UA]

Bon ca avance, j'ai retrouvé la source de la DLL WHTTP, mais c'est du delphi 7 et j'utilise du delphi 6 donc j'aimerais bien ne pas y toucher

sinon l'erreur semble venir d'un parametre totalement bidon :
la fonction de la DLL attend un PChar, je lui donne Nil.
Elle compire le Pchar a nil et agit en conséquence.

Sur la version non découpée, la DLL reconnait le nil et fonctionne bien.
Sur la version découpée en DLL, la fonction renvoie l'erreur.
Si je met un string a la place du Nil, ca marche ...... mais ca change le fonctionnement de la fonction vu qu'elle compare le parametre avec Nil

je vais continuer a chercher

NIL de delphi 6 différent de Nil de delphi7 ?

[FM_UA]

Bon j'ai fait des tests.
Et c'est encore plus étrange...

En lançant la fonction de la dll WHTTP.dll a partir:
_de l'exe : ça marche.
_à partir de la fonction exportée de la DLL intermédiaire : ça marche.
_à sa place dans la procédure appelée par la fonction exportée de la DLL intermédiaire : ça marche pas

Qu'est-ce qui se passe ?


EDIT: it's magic En mettant en commentaire une ligne de code (Session.free), ça plante pas. Le problème c'est que la procédure n'utilise pas Session... Et que Session.free ne provoque pas d'erreur dans les autres DLL....