Discussion :

[cbegood]

Bonjour,

je programme une application et je me retrouve face a un sérieux problème.
De temps en temps (c'est à dire pas a chaque lancement du programme) un bug se produit et je n'y comprend rien je vous donne toutes les infos que j'ai:

dans l'event log:

Code :

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

First chance exception at $7C812A5B. Exception class EAccessViolation with message 'Access violation at address 00401A4F in module 'TrialManager.exe'. Write of address 00000004'. Process TrialManager.exe (1024)

dans le Call stack:thread 1564:

Code :

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

1
2
3
:7c812a5b kernel32.RaiseException + 0x52
:00404b7c NotifyNonDelphiException + $1C
:7c91378b ntdll.RtlConvertUlongToLargeInteger + 0x46

dans la CPU:ligne pointée:

Code :

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

7C812A5B 5E               pop esi

Je ne sais pas si le reste est utile.

Si vous pouvez m'aider a comprendre Merci.

[vanquish]

Bonjour,

Visiblement il y a un cast (implicite ?) d'un entier 64 bit non signé en 64bits signé.

Si la valeur est petite, le cast se fait sans perte de donnée (et ça passe).
Si la valeur est grande, le nombre de valeur positive étant moitié moindre dans un entier signé, tu as une exception, car il y a perte de donnée significative.

Puisque cela semble aléatoire, j'aurais pensé à un entier fourni par le système, comme un handle de fenêtre - mais ce n'est pas cela puisqu'un handle n'est que sur 32 bits.

Tu n'arrive pas à avoir la pile d'appel, plus longue que cela ?

[tourlourou]

vanquish a probablement raison.

mais ce qui est étonnant est d'obtenir un EAccessViolation au lieu d'un EConvertError...

sinon, le pop esi de la fenêtre CPU est dans la routine qui traite l'exception => ne renseigne pas sur le pb

il serait sympa de savoir qui appelait la fonction de conversion

[cbegood]

Tu n'arrive pas à avoir la pile d'appel, plus longue que cela ?

J'envoi une image de mon écran ça sera plus simple je pense.



Merci

[cbegood]

Alors j'ai modifié un détail dans mon code et il semble que ce bug a disparu (bien que ce soit difficile d'être certain car je ne connaissais pas vraiment la procedure qui le faisait apparaître).

D'où une autre question:

Je vais prendre un exemple:

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
unit MAIN;
 
interface
 
uses Windows, SysUtils, Classes, Graphics, Forms, Controls, UTest;
 
type
  TMainForm = class(TForm)
 
  private
    { Private declarations }
    procedure CreateMDIChild;
  public
    { Public declarations }
  end;
 
var
  MainForm: TMainForm;
  Test: TTest;
 
implementation
 
{$R *.dfm}
 
procedure TMainForm.CreateMDIChild;//relièe à MainFormOnCreate
begin
 
   Test:=TTest.Create(Application.MainForm);
 
end;

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
33
34
35
36
unit UTest;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, Menus;
 
type
  TTest = class(TForm)
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    { Private declarations }
  public
    { Public declarations }
  end;
 
 
implementation
 
{$R *.dfm}
 
uses Main;
 
procedure TTest.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Action:=caFree;
 
//Comment supprimer Test dans Main?
Main.Test:=nil;
Test:=nil;
//Et pourquoi l'un plutôt que l'autre?
 
end;
 
end.

Voilà la question est en commentaire dans l'unit UTest.
En gros dans mon application j'utilisais Main.Test:=nil; et en utilisant Test:=nil; le bug semble avoir disparu.
Est-ce un hazard ou ai-je mal compris quelque chose?

Merci

[cbegood]

Rectification le bug est toujours là!!!

[tourlourou]

je me demande si tu ne déclares pas MainForm comme Owner de Test dans son Create => je ne suis pas sûr qu'il faille nihiler Main.Test !

disons que si tu te charges de libérer Test, lui faut-il un owner ? faire un Create(nil) éviterait pê des soucis (sauf si MainForm.Free doit libérer Test s'il n'a pas été libéré avant...)

[rsc]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
procedure TTest.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Action:=caFree;
 
//Comment supprimer Test dans Main?
Main.Test:=nil;
Test:=nil;
//Et pourquoi l'un plutôt que l'autre?
 
end;
 
end.

A mon sens, ce code pose problème :
Tu n'as pas besoin de détruire ton objet, puisque tu passes à son OnClose un paramètre caFree. Mais tu annules ta référence à l'objet dans une procédure de l'objet lui-même, ce qui est proprement acrobatique. Du coup, l'appel au destructeur va se faire sur une référence devenue invalide. Je suppose que selon que les données à cette adresse ont été écrasées ou non, ça plantera ou non, ce qui peut donner cet aspect aléatoire au bug.

[cbegood]

Je comprend plus ou moins ta remarque Roland, mais le bug ne se produit pas a la fermeture de la fenêtre donc cette procédure n'est pas en cause je pense?
Je vais tout de même regarder pour changer cela merci.