(Delphi 7, XP) Runtime Error + crash

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 :cry:
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 :aie: (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 :scarymov:
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 ;)

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

Merci pour les pistes :ccool:
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 :)

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:

---

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:

---

FreeAndNil(Obj);

---

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

Code:

---

myvar := nil;

---

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 :?

Tu n'utiliserais pas une DLL qui libérait des données venant du programme ?

Il y a bien des DLL qui sont utilisées quand y a besoin, mais si je me contente (contentais) de lancer le programme et de le fermer, j'avais les erreurs
Et par défaut, une seule Form et aucune utilisation trouvée de DLL personnelle. En +, les modifications apportées étant mineures, c'est troublant de voir des erreurs pareilles. Elles auraient dû apparaître avant !

Mais oui, l'idée de mauvaise libération d'objet (genre objet d'une autre unité) me plaît bien

sympa de partir en week end avec cette épine en moins :D

Merci pour l'aide (normalement, je ne suis pas prêt de poster :P)

bien sur il faut apprendre l'habitue de le faire dans toutes les classes même des type integer,record peuvent poser des problème

Code:

---

1 2 3 4 5 6

destructor TMaclass.Destroy(); begin Obj.Free(); Obj:=nil; inherited; end;

---

sans oublier les problème liés a la synchronisation des threads un showmessage dans un thread secondaire pose le même problème ainsi la libération d un même object simultanément

Citation:

---

Envoyé par alf_idsoft

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 :?

---

A priori, si ton exe partage des string avec une dll, (parametre de procedure, objets, ...), alors c'est sûr que ca vient de là. J'ai deja rencontré le même probleme, et c'est vrai que ca peut arriver à un moment quelconque.
Je pense que c'est dû aux emplacements memoire utilisés. Une variable de plus déclarée, qui va prendre un emplacement memoire qui contenait des 0 auparavant, et qui est comme par hasard l'emplacement précédemment utilisé par une chaine, et c'est le drame. (m'enfin ca reste une supposition personnelle)

Citation:

---

Envoyé par guillemouze

A priori, si ton exe partage des string avec une dll, (parametre de procedure, objets, ...), alors c'est sûr que ca vient de là. J'ai deja rencontré le même probleme, et c'est vrai que ca peut arriver à un moment quelconque.

---

j'ai cru que delphi gère cela automatiquement il la fonction LStrAsg; LStrLAsg qui force la création de nouvelle chaine pas seulment pour les dll mais aussi pour les constante interne

le probleme des string, c'est que les exe en delphi gerent en interne les pointeurs alloués pour les chaines, et les libere quand ils ne sont plus utilisés (un peu comme les intefaces). Mais le probleme, c'est que quand tu passe une chaine a une dll, ton exe et la dll ne partagent pas les infos internes de gestion des chaines, et donc (je pense) essayent tous les deux de posseder la chaine. Ce que borlandmm.dll (via le uses ShareMem) se charge de faire.