Discussion :

[alf_idsoft]

Bonjour,

Depuis des années que je consulte Developpez.com, je poste mon 1er message !
D'habitude je trouve toujours mais là, ça m'inquiète un peu

Alors voilà le décor :
Je fais parti d'une équipe de développeurs Delphi. Nous avons plusieurs applications utilisées par des dizaines de personnes (postes XP et 2000).
Nous faisons des mises à jour de temps en temps, il y a un gestionnaire de version (VSS) et des unités communes aux différents projets (pas forcément bien rangées, mais bon, c'est comme ça). La base de données est Oracle 10g.

Il y a quelques temps je rajoute une fonctionnalité dans l'application "A". Ca marche, aucun problème.
J'ai rajouté la même fonctionnalité sur l'application "B" et là, ça marche moins bien
La fonctionnalité en question rajoute une classe descendante de TForm et certains écrans dérivent alors de cette TForm-Bis, en utilisation un datamodule. Rien de violent quoi.
Depuis, tous les utilisateurs ont une Runtime Error 216 en quittant l'application "B" ! Si je débuggue, ça plante dans les unités Delphi, tellement loin que je n'ai que le code assembleur ! (version Delphi Entreprise)
J'ai fait quelques modifs supplémentaires dans une unité et alors là, ça devient grave quand on lance l'exé : "L'application B a rencontré un problème et doit fermer (...)" 7 fois de suite (en plus du runtime)
Essai sur un autre poste : pareil !
En lancement depuis Delphi, c'est aléatoire, j'ai au moins 1 runtime, sinon une infinité (erreurs 216, 217, 204 aussi je crois)
(En dehors de ça, l'appli marche très bien)

J'ai beau désactiver du code (celui que j'avais rajouté avant d'avoir le 1er runtime), rien à faire.
Quant à désactiver l'hyperthreading comme j'ai lu, ça a bien fait marrer dans le bureau
Je n'ai par ailleurs pas vu d'unité "JclSysInfo.pas"
Et même, trafiquer les sources Delphi pour des applis qui ont prêt de 10 ans et qui sont essentiels à plein d'utilisateur, je suis pas chaud

Si vous avez des idées pour m'aider, je vous en remercie

[ShaiLeTroll]

C'est assez typique d'un oubli de inherited dans un Destroy ou de la libération d'un objet déjà libéré dans une section finalization (par leur Owner ou ObjectList par exemple)

JclSysInfo c'est dans la lib JEDI

[alf_idsoft]

Merci pour les pistes
En +, y a peu de Destroy et surtout je n'ai pas souvent l'occasion d'en coder
Restent les Free
Et là, j'ai de quoi faire, surtout que certains ont été rajoutés....

je continue à creuser, merci

[ShaiLeTroll]

Normal, que tu as peu de Destroy, il n'est utilisé uniquement que lors de l'héritage du destructeur, jamais ailleurs ...

Dans le code, on appelle Free (ou FreeAndNil), c'est qui se charge d'appeler Destroy ...

Au plus que possible utilise FreeAndNil sur les Objets Globaux ou les Objets membre d'un autre Objet, cela protège contre les libérations multiples ...

Je préfère mettre les 2 lignes, j'ai ainsi bien conscience ce de que je fais, j'ai vu bcp de FreeAndNil sur des variables locales sans aucune raison

Code :

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

1
2
Obj.Free
Obj := nil;

ou pour un code plus court, mais je trouve cela moins joli (le côte procédural surement)

Code :

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

FreeAndNil(Obj);

[Montor]

la libération d'une constant,variable globale peut le produire
au besoin

Code :

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

myvar := nil;

[alf_idsoft]

C'est de bonnes habitudes à prendre, effectivement !
Par contre, y a presque 1 million de lignes de codes (j'exagère pas tant que ça) donc des free manquants, y en a des tonnes (j'ai même fait un programme qui tente de les détecter), des freeandnil, encore pire
Et c'est un sacré danger et bien trop de temps pour réparer le tout

N'empêche que j'ai trouvé (mais j'ai un doute) une solution, presque par hasard : j'ai ajouté ShareMem dans les uses du projet
Et miracle, plus aucune erreur en sortant
M'enfin je trouve ça très louche la façon dont les erreurs sont venues et reparties