Bug incompris non récurrent

Version imprimable

18/12/2008, 09h04
cbegood

Bug incompris non récurrent
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:

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:

1 2 3 :7c812a5b kernel32.RaiseException + 0x52 :00404b7c NotifyNonDelphiException + $1C :7c91378b ntdll.RtlConvertUlongToLargeInteger + 0x46
dans la CPU:ligne pointée:

Code:

7C812A5B 5E pop esi

Je ne sais pas si le reste est utile.

Si vous pouvez m'aider a comprendre :( Merci.
18/12/2008, 09h43
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 ?
18/12/2008, 10h12
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
18/12/2008, 10h49
cbegood

Citation:

Envoyé par vanquish

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.

http://www.developpez.net/forums/u252654-a95-i310.jpg

Merci

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:

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:

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

18/12/2008, 14h21
cbegood

Rectification le bug est toujours là!!!

:bug:
18/12/2008, 18h53
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...)
19/12/2008, 08h41
cbegood

Alors j'ai testé avec un Create(nil) mais cela ne change rien.
Je ne comprend vraiment pas.
Il semblerait que j'ai trouvé la suite d'événements qui conduit a ce bug mais je ne vois pas d'explication.

La voici:

Dans ma fenêtre Main, je peux créer un nouveau "projet" qui m'ouvre une fenêtre de sauvegarde pour choisir l'emplacement et ensuite crée un TreeView dans ma fenêtre Main.
Ensuite en clickant sur l'un des nœuds du TreeView, des fenêtres filles peuvent s'ouvrir. Il me semble que le bug ne se produit que dans une seule de ces fenêtres filles qui contient un PageControl. C'est lorsque je click sur le bouton qui me fait changer de Tab dans le PageControl que le bug se produit.

Étonnamment, si je fais les mêmes opérations avec un "projet" créé auparavant donc que je ne fais qu'ouvrir (par une fenêtre d'ouverture de dossier), le bug ne se produit pas d'où mon incompréhension.

Surtout qu'il ne s'agit pas d'un bug de création ou de copie de dossier ou quoique ce soit de ce genre.

Aidez moi s'il vous plaît ...

Citation:
Envoyé par cbegood
Code:

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.

19/12/2008, 09h26
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.
19/12/2008, 15h36
vanquish

Car, même s'il n'est pas en cause, ce qui me chagrine dans ton code de FormClose c'est que :
- je ne vois pas comment les 2 lignes peuvent désigner le même objet (où alors il manque du code). Test est une variable globale. Pas un membre de Main.
- Tu nil trop tôt. A l'événement FormClose ta fenêtre existe encore pour un moment.

Si le pas à pas ne te montre rien, mais que tu arrive à reproduire de façon régulière, met des points d'arrêts dans tous les événements ou presque. Tu passe peut-être à un endroit que tu ne pense pas.

L'ordre des événement est parfois illogique.
Par exemple, on a parfois des événements sur des contrôles après être passé par le FormDestroy (qui généralement fait du nettoyage).

C'est le cas des ListView où on a une ultime déselection d'item alors que la fenêtre n'est même plus censé exister. Le Treeview a peut-être des comportement similaire.
19/12/2008, 15h59
tourlourou

Citation:

C'est lorsque je click sur le bouton qui me fait changer de Tab dans le PageControl que le bug se produit.

à qui appartient ce bouton ? au TreeView ? à une fiche ?
quel code déclenche-t-il ?
n'y a-t-il pas de pb d'indice ?
19/12/2008, 16h02
rsc

Citation:

Envoyé par vanquish

- je ne vois pas comment les 2 lignes peuvent désigner le même objet (où alors il manque du code). Test est une variable globale. Pas un membre de Main.

Main n'est pas une classe, c'est une unité. Ecrire Main.Test indique simplement sans ambigüité où chercher la variable ;)