Discussion :

[GerardJ]

Bonjour,
je rouvre la discussion car il s'agit d'un problème apparenté.
Depuis douze ans je fais tourner des serveurs qui appellent sans problème plusieurs centaines de milliers de fois par jour une DLL au travers d'un stdCall.
Or sur un ordinateur plus récent, ces serveurs plantent. J'ai essayé sur un autre ordinateur récent : même problème. (violation d'accès)
Je dispose de Delphi 10.2 pour examiner le problème. Mais en mode debug de l'EDI le serveur marche parfaitement. Il n'y a qu'en compilé que le problème se produit. J'ai essayé le mode administrateur sans succès.
en explorant un peu le code j'en suis arrivé à la conclusion que c'était l'appel à la DLL qui provoquait l'erreur. J'ai alors supprimé le StdCall : l'erreur disparait mais les résultats sont erronés.
Il semblerait bien que ce soit lié aux ordinateurs récents...
quelqu'un a une idée ?

[SergioMaster]

quelqu'un a une idée ?

Un problème de nombre de Bits 32/64 ?

[GerardJ]

les ordinateurs sur lesquels ça fonctionne sont tous des 64 bits avec des cores I7 de 4ème génération. Un windows 10 famille (après upgrade) et l'autre W7 pro
Celui sur lequel il y a des problèmes est aussi 64 bits core I7 de 7ème génération. W10 famille

[ShaiLeTroll]

En même temps, en 64bits, il n'y a plus de convention d'appel spécifique, il n'y a plus qu'une seule convention le __fastcall
Tout ça c'est valable pour les programmes 32Bits qui doivent effectivement conservé le register/pascal en interne et le stdcall/safecall pour l'extérieur

[GerardJ]

Merci pour vos informations mais ceci n'éclaire pas encore ma lanterne...
Suite à ton dernier post j'ai essayé de remplacer stdcall par safecall : toujours le même problème. Fastcall n'est pas reconnu par le compilateur.
La question est pourquoi un programme qui tourne depuis longtemps sur des machines 64 bits cesse de tourner sur des machines plus récentes avec le même type de CPU ?
Pourquoi le programme tourne sur ces machines plus récentes en mode debug de l'EDI Delphi 10.2 mais pas en compilé ?

Mon problème est critique : mon site tourne actuellement sur les machines anciennes et si l'une d'elles tombe en panne, je n'ai pas de solution pour continuer...
Un ami m'a dit qu'intel avait introduit une sécurité supplémentaire dans ses puces : serait-ce là le problème ?

[Paul TOTH]

alors petits rappels

1) une appli 32 bits, tourne en 32 bits, même sur une OS 64bits (une application 64Bits ne peut pas tourner sur un OS 32bits)

2) les applis 32 bit ne sont pas compatibles avec les DLL 64bits et vice versa

3) la convention d'appel ce n'est pas une option qu'on peut changer comme on veux, ce doit être cohérent entre l'appelant et l'appelé, suivant le choix qui est fait, les paramètres sont passés de droite à gauche ou de gauche à droite, via des registres ou sur la pile, en laissant l'appelant nettoyer la pile ou en le faisant après l'appel...donc, sauf cas rares (procédure sans paramètre ou avec un seul paramètre qui passe dans un registre), on ne peux pas mettre n'importe quoi comme convention d'appel, il faut absolument choisir la bonne option. De Delphi à Delphi, il suffit de mettre la même option des deux côtés, de Delphi vers un autre langage, c'est généralement stdcall qui est utilisé sous Windows...mais pas toujours. safecall est utilisé pour remplacer une fonction retournant un HRESULT dans le cadre des appels COM (ActiveX).

4) la convention d'appel ne change pas en fonction du processeur.

je recommande l'usage de madExcept pour débuguer les violations d'accès ou fuites de mémoire, c'est un produit excellent ! Il ne permet pas de tout identifier mais pointe souvent dans la bonne direction.