Discussion :

[adaneels]

Bonjour,

Je mets un sujet là-dessus parce que ça fait des mois que je trouve des AccesViolationException avec le message: "Tentative de lecture ou d'écriture de mémoire protégée. Cela indique souvent qu'une autre mémoire est endommagée." dans une application un peu "stressée" sans savoir pourquoi.

Après avoir enfin réussi à reproduire, j'ai le message "erreur de vérification étendue" lorsque l'exception est levée en mode debug.

Je viens de trouver que cela provient d'un problème de conversion entre des System.string (type .NET 2) et Borland.Delphi.System.String (type Delphi).

Je suis sous Rad Studio Delphi 2007.

je déclare mes string de la façon suivante :

Code :

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

1
2
var s : string;
    obj : TObject; // ou obj : &Object;

L'exception AccessViolationException est levée lorsque je fais

Code :

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

s:= obj.ToString;

La raison est que s est un Borland.Delphi.System.String alors que ToString renvoie un System.string.

Et des ToString (ou d'autres fonctions .NET qui renvoient des System.String), il y en a beaucoup sur des Dataset ou autres objets .NET dans l'application que je gère.

La solution à ce problème est d'éviter le ToString si possible ou d'utiliser System.String à la place de string dans la déclaration (non testé pour l'instant).


Je ne sais pas si ça vaut une faq ou quoi mais je pense que ça a le mérite d'être au moins mis sur le forum.

Cordialement,
Arnaud DANEELS

[Laurent Dardenne]

Salut,

Je viens de trouver que cela provient d'un problème de conversion entre des System.string (type .NET 2) et Borland.Delphi.System.String (type Delphi).

Il s'agit de la même chose, le String est mappé sur System.String. Ce qui est ajouté c'est juste un class helper sur TObject.

Le code suivant ne provoque aucune erreur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
program Project2;
{$APPTYPE CONSOLE}
{$R+} // ou {$R-}
uses
  SysUtils;
var s : System.String;
     // ou s : String;
    obj : TObject;
    obj2 : &Object;
begin
  try
  s:='test';
  obj:=TObject.Create;
  obj2:=&Object.Create;
  Writeln('Type');
  Writeln(S.GetType);
  Writeln((Obj.tostring).GetType);
  Writeln('Contenu');
  Writeln(S);
  Writeln(Obj.tostring);
  Writeln(Obj2.tostring);
  S:=Obj.tostring;
  Writeln(S);
  S:=Obj2.tostring;
  Writeln(S);
  Readln;
  except
    on E:Exception do
      Writeln(E.Classname, ': ', E.Message);
  end;
end.

Je doute de l'explication concernant la cause du pb que tu rencontres
D2007 patché, XP Sp2, Fx 2.0 patché

[adaneels]

Salut,

Il s'agit de la même chose, le String est mappé sur System.String. Ce qui est ajouté c'est juste un class helper sur TObject.

Le code suivant ne provoque aucune erreur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
program Project2;
{$APPTYPE CONSOLE}
{$R+} // ou {$R-}
uses
  SysUtils;
var s : System.String;
     // ou s : String;
    obj : TObject;
    obj2 : &Object;
begin
  try
  s:='test';
  obj:=TObject.Create;
  obj2:=&Object.Create;
  Writeln('Type');
  Writeln(S.GetType);
  Writeln((Obj.tostring).GetType);
  Writeln('Contenu');
  Writeln(S);
  Writeln(Obj.tostring);
  Writeln(Obj2.tostring);
  S:=Obj.tostring;
  Writeln(S);
  S:=Obj2.tostring;
  Writeln(S);
  Readln;
  except
    on E:Exception do
      Writeln(E.Classname, ': ', E.Message);
  end;
end.

Je doute de l'explication concernant la cause du pb que tu rencontres
D2007 patché, XP Sp2, Fx 2.0 patché

Merci, vos conseils sont toujours aussi utiles !

J'ai commencé à utiliser partout le même type mais la décision de refondre la solution en C# a été prise donc on stabilise et on recommence.

Va vraiment falloir que j'écrive les articles que je m'étais noté sur des coins de feuilles parce que je risque fort d'avoir la tête plongée dans d'autres langages prochainement !

3ème application Delphi à laquelle je participe à une refonte en C#... mais c'est un autre débat.

J'y regarderai de plus près tout de même pour ma connaissance perso.
Merci.

---

Pour plus de détails sur le problème, c'est assez ardu :
J'ai eu ces violations d'accès sur des string, j'ai commencé à épurer le code correspondant. Au final, j'ai des violations d'accès sur la méthode TAdoDbxCommand.executereader, avec une requête qui fonctionne parfaitement. En fait, c'était du à une gestion des connexions à la base de données (très) mal pensée (ou bien pensée s'il on ne faisait qu'une dizaine de connexions).

Une fois la gestion de connexion vite modifiée, je n'ai plus de violations d'accès, même en remettant le code comme avant où j'avais des string qui ne se convertissaient pas.

Le rapport entre ça et les violations d'accès sur des strings ?
Je n'en sais rien, même en essayant de regarder les adresses des mémoires allouées, je n'ai pas réussi à voir (mais je n'y ai pas passé des heures).

L'explication : j'en ai aucune. Ça vient certainement du code source que l'on a écrit mais je ne comprends toujours pas pourquoi ça a lancé des violations d'accès lorsque l'on fait une conversion implicite sur des types qui sont, comme vous dites, identiques.

Je regarderai plus en détail la semaine prochaine.
Si je trouve quelque chose, je le mettrai ici.

Merci encore,
Arnaud Daneels

[Laurent Dardenne]

3ème application Delphi à laquelle je participe à une refonte en C#... mais c'est un autre débat.

La décision clôt le débat

Le rapport entre ça et les violations d'accès sur des strings ?
Je n'en sais rien, même en essayant de regarder les adresses des mémoires allouées,

Ceci me semble être une démarche incorrecte sous .NET puisque le garbage collector peut être amenné à déplacer les objets lors d'une collecte.
L'analyse de la pile d'appel de l'exception ne donne rien ?

Le rapport entre ça et les violations d'accès sur des strings ?

Il y a peut être un mixte de code Win32 et .NET, ou des options de compilation qui pose pb, voir la présence de code Unsafe...

sur des types qui sont, comme vous dites, identiques.

C'est surtout le compilateur (compatible CLS) qui le dit et s'il en existait un de différent on devrait le retrouver dans le code source de Delphi .NET.

[adaneels]

Ceci me semble être une démarche incorrecte sous .NET puisque le garbage collector peut être amenné à déplacer les objets lors d'une collecte.
L'analyse de la pile d'appel de l'exception ne donne rien ?

Je regarde toujours la pile d'appel (et les innerexceptions), rien qui m'a marqué et dont je me souvienne. Je regarderai. (ne pas hésiter à faire un message s'il vous semble que j'oublie ).

Il y a peut être un mixte de code Win32 et .NET, ou des options de compilation qui pose pb, voir la présence de code Unsafe...

Un mixte de code Win32 et .NET : oui, il y a un peu de Win32
options de compilation qui pose pb : c'est possible, je ne parierai pas une caisse de Petrus vielle brune que tout est parfait de ce côté là.
code unsafe : non

C'est surtout le compilateur (compatible CLS) qui le dit et s'il en existait un de différent on devrait le retrouver dans le code source de Delphi .NET.

ok

je reprends le message prochainement avec plus de réponses.


Nota Bene : "Vir bonus est is, qui prodest quibus potest, nocet nemini"