Discussion :

[PetitBoutDeCode]

Bonjour,

Récemment j'ai trouvé un bug dans mon application FMX en utilisant des Threads (erreur de segmentation(11)).

J'avais pris pour habitude de créer mes objets en utilisant .Create(Self) mais de temps en temps, ça plante .

J'ai modifié la création de mes objets avec .Create(Nil) et depuis je n'ai plus ce problème!

Exemple de fonction :

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
37
38
procedure TData.GetPlanning(DateProd : String;T : TVirtualTable);
Begin
  tthread.CreateAnonymousThread(
  procedure
  var
      Client   : TRestClient;
      table    : TVirtualTable;
      Request  : TRestRequest;
      Response : TRestResponse;
      Adapter : TRestResponseDataSetAdapter;
  begin
  Table := TVirtualTable.Create(Nil);
  Table.Open;
  T.Clear;
  Client   := TRestClient.Create(Nil);
  Request  := TRestRequest.Create(Nil);
  Adapter := TRestResponseDataSetAdapter.Create(Nil);
  Response := TRestResponse.Create(Nil);
  Adapter.Response := Response;
  Adapter.Dataset := Table;
  Request.Client := Client;
  REquest.Response := Response;
  Client.BaseURL := BASE_URL2;
  Client.AddParameter('action','get_planning_bis');
  Client.AddParameter('date_prod',DateProd);
  Request.Execute;
  tthread.Synchronize(nil,
  procedure
  begin
    if Not Table.IsEmpty then
    Begin
      T.Assign(Table);
      T.FieldByName('id').Visible := False;
      T.FieldByName('decouverte').Visible := False;
    End;
  End);
  end).Start;
End;

J'ai pu lire dans un autre post que Create(Self) sers à gérer la destruction des composants à la destruction du Owner, mais je ne vois pas pourquoi dans mon cas cela a une incidence...?

[Paul TOTH]

Bonjour,

tout à fait, attribuer un Owner permet de s'assurer que l'objet est détruit quand son Owner est détruit...mais ça implique donc que l'objet existera jusqu'à ce que le Owner soit détruit (ça peut être long)

Le problème ici c'est que tu fais cette création depuis un Thread secondaire, et là c'est risqué car on ne sait pas ce que le Owner est en train de faire pendant ce temps dans le thread principal.

Donc il est tout à fait valide de ne pas mettre de Owner (nil) mais dans ce cas il faut explicitement libérer l'objet quand il n'est plus utile...en l'occurrence tu ne détruis aucun des objets créé dans le thread.

à priori ton code pourrait s'écrire comme ceci

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
37
38
39
40
41
42
43
44
 
procedure TData.GetPlanning(DateProd : String;T : TVirtualTable);
Begin
  tthread.CreateAnonymousThread(
  procedure
  var
      Client   : TRestClient;
      table    : TVirtualTable;
      Request  : TRestRequest;
      Response : TRestResponse;
      Adapter : TRestResponseDataSetAdapter;
  begin
  Table := TVirtualTable.Create(Nil);
  try
    Table.Open;
    // T.Clear; <-- ça me semble de trop et à ne pas faire dans le Thread, éventuellement dans le Syncrhonize
    Client   := TRestClient.Create(Table);
    Request  := TRestRequest.Create(Table);
    Adapter := TRestResponseDataSetAdapter.Create(Table);
    Response := TRestResponse.Create(Table);
    Adapter.Response := Response;
    Adapter.Dataset := Table;
    Request.Client := Client;
    REquest.Response := Response;
    Client.BaseURL := BASE_URL2;
    Client.AddParameter('action','get_planning_bis');
    Client.AddParameter('date_prod',DateProd);
    Request.Execute;
    tthread.Synchronize(nil,
    procedure
    begin
      T.Clear; // ici
      if Not Table.IsEmpty then
      Begin
        T.Assign(Table);
        T.FieldByName('id').Visible := False;
        T.FieldByName('decouverte').Visible := False;
      End;
    End);
  finally
    Table.Free;
  end; 
  end).Start;
End;

on s'assure que Table est détruit, et en le nommant Owner des autres, ils le sont aussi

[PetitBoutDeCode]

Je pensais (naivement) que les composants étaient libérés automatiquement à la fin de la fonction .

Pour le T.Clear, je me suis dis que ce n'était pas ce qui allait ralentir le tout, mais comme on dit qui peut le plus peut le moins c'est vrai que c'est plus logique comme ça ..!

Et c'est vrai que je n'avais pas penser à tout affecter à un composant pour en avoir qu'un à libérer, c'est tout bête, mais sur la centaine de fonctions que je vais reprendre c'est un gros gain de temps !!

Merci !!