Discussion :

[ShaiLeTroll]

je pense que les réponses n'ont pas exactement pris en compte la situation.

Nous n'avons qu'une seule information : Une violation d'accès en écriture dans une version release lancée sans débug

Tous les ordinateurs sont des core I7 quadricœur.

Pour c'est ça un vieil ordinateur
On parle d'un vieux programme D7, j'ai pensé donc à la technologique de l'époque soit donc des PIV HT pouvant faire tourner deux threads en vrai simultané et non via un ordonnancement tour à tour.
Et "Depuis douze ans", j'admets ça pouvait plutôt être de "Core 2 Quad Core" donc dans l'ère du multi-threading optimisé mais votre problème de VA qui ne se produit pas en DEBUG faisait tellement pensé à un problème de collisions entre thread

Je n'avais pas effectivement compris que les vieux ordinateurs étant des "64 bits avec des cores I7 de 4ème génération" et le nouveau un "7ème génération"
Et que le mien est aussi un i7 de 4ème génération, mon pauvre vieil ordinateur que j'ai a peine depuis 3 ans ... dire qu'il est un veillard comme ma tour qui a justement un "Core 2 Quad Core" et au mieux un D7 Perso dessus (je ne sais même pas si elle démarre si je la branche)
Et dire que l'on a des serveurs encore plus vieux au bureau

Je remarque surtout que l'on obtient pas de vous les réponses à nos questions

... le prototype de la fonction, des détails sur l'appelant et l'appelé, le contexte de compilation (32 ou 64), alignement mémoire, le gestionnaire de mémoire utilisé, ... le type de VA avec les adresses permettant de savoir si c'est lié à un pointeur nil ou une utilisation d'un pointeur non valide ...

nous avons un début, le prototype de fonction

Code :

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

procedure wb_dll(H:pTjeu;C:ptconv;I_eval:integer);stdcall; external 'wbtot_wb.dll';

On ne sait ni ce que contient pTjeu ni ptconv
La mémoire si elle correctement allouée, avec le bon alignement, soit en packed explicite dans le code de déclaration, en directive de compilation sur l'unité ou même dans les options de projet
Par habitude, je ne fais jamais de external, préférant un LoadLibrary et GetProcAdress que pour mon programme soit robuste à l'erreur en cas de DLL manquante ou ne pouvant pas se lancer.
La mémoire si bien allouée n'est elle pas libérée trop tôt ou modifiée à un mauvais moment, la DLL pouvant ne pas apprécier que l'on joue avec la mémoire des pointeurs que lui a fourni, tout cela nous ne le savons pas, nous ne pouvons que vous donner des pistes, nous n'avons le code sous les yeux pour comprendre les évidences qui ne le sont qu'à vos yeux.

...J'ai alors supprimé le StdCall : l'erreur disparait mais les résultats sont erronés.

Quels résultats ?
On voit une procédure, il y a une autre fonction ? un pointeur d'entrée et l'autre de sortie ? un fichier ?
Mystère !
On ne voit que les entrées avec les données de requêtes pTjeu, les conventions ptconv et l'indice I_eval pour le numéro d'opération
Aucun résultat à l'horizon, on ignore si c'est un appel bloquant ou asynchrone utilisant un CallBack par exemple

j
Ce n'est pas non plus un problème de génération d'EDI : les programmes que j'ai faits l'ont été avec Delphi 7 et ils tournent sur les "anciens" ordinateurs pas sur les récents. Je n'ai utilisé Delphi 10.2 que pour essayer de cerner le problème posé sans changer le code initial.

N'avoir aucune modification pour passer de D7 à D10.2 sans impact de l'Unicode, cela relève du miracle, je n'accorde aucun crédit à ce test si aucunes mesures sur la manipulation string<>PChar n'ont été prises
Peut-être un problème de lancement en mode administrateur
Nous ne savons pas si le programme est simple Exe ou un Service Windows quoi que ceci m'indique donc un accès au bureau puisqu'il y a une fenêtre

...Pour tracer où cela plante, j'ai utilisé la fenêtre d'affichage du serveur...

Combien de fois, j'ai pu voir un affichage parasiter tout un programme serveur ... rien que le ralentissant, ça réduisait les conflits.

Il me semblait avoir décrit la nature de l'erreur : violation d'accès en écriture...
Je commence à me demander si je vais trouver la raison et une solution sur ce forum..

Ce n'est pas de notre faute si vous ne répondez à nos questions !
Une violation d'accès peut venir de raison totalement imprévisible

Par exemple, il y a un tableau, le programme écrit dedans mais il déborde sur l'espace mémoire suivant, pas de bol, en mémoire c'était l'emplacement d'un pointeur
Et à un moment, le programme va écrire dans l'emplacement mémoire indiqué par ce pointeur mais dont la valeur a été corrompue
Résultat, un bug à un endroit X provoque une violation d'un code Y

[Paul TOTH]

de tête, le seul problème en passant sur des CPU récentes, il était dans l'unité CRT de Turbo Pascal, elle plantait sur tout CPU à plus de 200 Mhz...je n'ai pas connaissance de ce genre de problème dans les unités standard Delphi...mais il est possible que ton code présente un bug lié à la vitesse d'exécution, notamment dans un environnement multitâches. Mais comme le dit Shai, sans boule de cristal, on ne peut pas deviner.

la violation d'accès est lié à une ligne de code bien précise qui fait une opération avec des variables dans un état non conforme. Tant que tu n'identifieras pas cette ligne, tu peux toujours courir pour trouver l'erreur.

comme déjà dit, madException ou des logs, ce sont les seuls moyens de s'en sortir, si tu ne veux pas ... ben tant pis pour toi.

[sergio_is_back]

difficile de croire que c'est une faute de programmation ; les serveurs sont nombreux sur différents ordinateurs et sont sollicités des milliers de fois par jour depuis 12 ans. Une faute de programmation n'aurait pas pu passer inaperçue donc peu probable et ne conduirait pas à une erreur systématique sur des ordinateurs récents. et quand je dis systématique j'ai fait d'innombrables essais qui plante tous.

Ça c'est déjà vu, des bugs non détectés et qui apparaissent suite à une modification de configuration

Ce n'est pas non plus une question multithread : non seulement je fais des essais avec un seul joueur donc un seul thread, mais en plus l'appli est conçue pour rejeter les demandes lorsqu'elle occupée.

A voir...

Il me semblait avoir décrit la nature de l'erreur : violation d'accès en écriture...

Y'a peu d'indications, il nous faudrait au moins le vidage de la pile d'appels...
Et quelques exemples de ton code...

Je commence à me demander si je vais trouver la raison et une solution sur ce forum.. à part remplacer mes vieux ordinateurs par des AMD.

Si l'on pas plus d'indications ça vite devenir une discussion qui tourne en rond et pas de notre fait, car comme l'a dit ShaiLeTroll nous ne sommes ni médiums ni marabouts... On ne lit pas l'avenir dans des boules de cristal mais dans les codes informatiques...

As-tu analysé les dépendances de la DLL comme je te l'avais suggéré ?

[ShaiLeTroll]

difficile de croire que c'est une faute de programmation ; les serveurs sont nombreux sur différents ordinateurs et sont sollicités des milliers de fois par jour depuis 12 ans. Une faute de programmation n'aurait pas pu passer inaperçue...

Tu serais surpris, j'ai corrigé un code justement migration D7 vers D10.1
Le programme manipulait les chaines avaient une mauvaise condition de sortie et pouvaient se balader trop loin en mémoire, curieusement sans aucun effet de bord avec le gestionnaire de mémoire NexusMM
J'ai repris le code, j'ai viré presque toutes utilisations de PChar pour revenir à un code plus simple en type natif string, plus performant, moins long.
Durant mes essais de test de performance pour trouver la forme la plus rapide et dans un contexte d'étude des gestionnaires de mémoire, j'ai pu constaté que code D7 non corrigé provoquait une violation d'accès en FastMM5 mais jamais en NexusMM et presque jamais en FastMM4
J'ai testé sur plusieurs machines à 4, 6 et 8 cœurs physiques (avec le double du nombre de thread que de cœur) et la même fonction qui tourne parfaitement sur NexusMM en mono-thread ne fonctionnait plus du tout si on la lançait en multi-thread car sa balade en mémoire allait bien plus loin et finissait mal.
Un erreur de programmation bien vicieuse peut se dissimuler des années !

Et pourtant la version D7 était utilisé tous les mois, plus jours de suite pour des générations de bundle applicatif sans soucis.

[anapurna]

salut

ton programme fait en D7 est installé dans quel répertoire de ton serveur ?
tu as peut être des problème de droit d’accès

[GerardJ]

J'ai enfin trouvé l'erreur et ça marche maintenant comme sur les autres ordinateurs.
Je suis hospitalisé depuis une semaine et ça ma laissé le temps de réfléchir. Toutefois avec teamviewer j'ai pu faire la modif et vérifier que cela marchait !
L'un d'entre vous a-t-il la moindre idée de ce qui peut être très évident ?
réponse demain

[Paul TOTH]

J'ai enfin trouvé l'erreur et ça marche maintenant comme sur les autres ordinateurs.
Je suis hospitalisé depuis une semaine et ça ma laissé le temps de réfléchir. Toutefois avec teamviewer j'ai pu faire la modif et vérifier que cela marchait !
L'un d'entre vous a-t-il la moindre idée de ce qui peut être très évident ?
réponse demain

ce qui est très évident c'est que sortir le nez de son problème amène souvent la solution...genre, aller aux toilettes, passer une bonne nuit, regarder un film...et revenir avec les idées claires.

dans ton cas, l'évidence n'est pas flagrante...mais sans doute nous manque-t-il quelques infos.

[GerardJ]

C'est bizarre les derniers posts ne s'affichent pas toujours sur mon ordi. Je savais qu'il y avait une réponse de Paul Toth mais je ne pouvais pas la lire ni mon post précédent. Pour ce faire il a fallu que je retourne en arrière et cliquer sur le lien de Paul.
la dernière fois je n'avais pas vu la réponse d'anapurna qui avait vu juste : le programme était installé dans le répertoire D: Lorsque je le mets dans C: il tourne sans problème,il reste à comprendre pourquoi une partition de disque a un effet sur la gestion de la mémoire.
Je rappelle que seul l'appel à la DLL plante : s'il est supprimé, le programme tourne normalement.
Merci de votre aide et bien vu anapurna !