convertion de string -> AccessViolationException

Version imprimable

04/12/2008, 13h23
adaneels

convertion de string -> AccessViolationException
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:

1 2 var s : string; obj : TObject; // ou obj : &Object;
L'exception AccessViolationException est levée lorsque je fais

Code:

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

Salut,

Citation:

Envoyé par adaneels

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:

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 :koi:
D2007 patché, XP Sp2, Fx 2.0 patché

Citation:
Envoyé par Laurent Dardenne
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:

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

12/12/2008, 22h02
Laurent Dardenne

Citation:

Envoyé par adaneels

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 ;)

Citation:

Envoyé par adaneels

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 ?

Citation:

Envoyé par adaneels

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...

Citation:

Envoyé par adaneels

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.
14/12/2008, 23h05
adaneels

Citation:

Envoyé par Laurent Dardenne

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 :mrgreen:).

Citation:

Envoyé par Laurent Dardenne

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

Citation:

Envoyé par Laurent Dardenne

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" :ccool: