TInterfacedObject i Runtime 204

0

Witajcie, jak głosi temat mam problem z TInerfacedObject, a dokładniej z jego zwalnianiem.
Mam sobię klasę TFoo, która wcześniej była zwykłą klasą tzn. Tfoo=class . Teraz, ze względu na przebudowę architektury, musiałem do niej dodać interfejs IFoo. Więc klasę przerobiłem na dziedziczącą z TInterfacedObject. Wszystko byłoby cacy, gdyby nie runtime 204, który otrzymuje przy wykonywaniu foo.Free();
Jak przeczytałem w dokumentacji jedynego słusznego kompilatora (http://www.freepascal.org/docs-html/rtl/system/tinterfacedobject.html) , a dalej w jego funkcji BeforeDestruction, "A runtime-error 204 will be generated if the reference count is nonzero when the object is destroyed.". Tylko nadal nie wiem, co ja na to mogę poradzić.
Dodatkowo, mam problemy z odpluskiwaniem, bo nigdzie nic nie wskazuje mi że instrukcja foo.Free wywołała błąd (zamiast tego bredzi coś o TForm.Destroy - w TForm1.FormDestroy jest foo.Free ).
Oczywiście korzystam z FPC i Lazarusa (najnowsze tj. 0.9.30).
Z góry dziękuję za pomoc.

0

Nie dajesz Free lecz przypisujesz nil

0
  1. mógłbyś z łaski swojej odpowiadać dodając nowy post a nie w komentarzu?
  2. jak zmienia się architektura na nieznaną to wypadało by się najpierw coś o niej dowiedzieć - poczytać o interfejsach, obiektach COM, co to jest licznik odwołań i dlaczego się ich nie zwalnia a przypisuje się im nil
0
Misiekd napisał(a)
  1. mógłbyś z łaski swojej odpowiadać dodając nowy post a nie w komentarzu?
  2. jak zmienia się architektura na nieznaną to wypadało by się najpierw coś o niej dowiedzieć - poczytać o interfejsach, obiektach COM, co to jest licznik odwołań i dlaczego się ich nie zwalnia a przypisuje się im nil
  1. Jakoś te komentarze bardziej mi leżą. Ale specjalnie dla Ciebie :-] .
  2. Dlaczego każdy do cholery zakłada że nic nie czytałem? Siedziałem na google dosyć sporo, eksperymentowałem, ale byłem święcie przekonany że albo coś muszę dodać w Destroy, albo inaczej wykonać Free.
    I jeszcze jeden problem, destruktor Destroy przerobiłem na procedure Done. W niej znajduje się DoneCriticalSection(bar); . I niestety otrzymuje błąd "raised exception: 'External: ?'". InitCriticalSection(bar); znajduje się w Create... Czyżby Create też się nie wykonywało?
    Tutaj macie call stack:
    #0 ntdll!LdrFlushAlternateResourceModules at :0
    #1 ntdll!LdrFindResourceDirectory_U at :0
    #2 ntdll!ZwCompressKey at :0
    #3 ntdll!EtwDeliverDataBlock at :0
    #4 SYSTEM_SYSDONECRITICALSECTION$formal at :0
    #5 SYSTEM_DONECRITICALSECTION$TRTLCRITICALSECTION at :0
    #6 TPRNDWN__DONE at prndwn.pas:415 (aka TFOO)
    #7 ?? at :0
    #8 TCUSTOMFORM__BEFOREDESTRUCTION(<error reading="reading" variable="variable">) at .\include\customform.inc:101
    #9 TCUSTOMFORM__DESTROY(0x1, <error reading="reading" variable="variable">) at .\include\customform.inc:115
    #10 SYSTEM_TOBJECT_$__FREE at :0
    #11 TAPPLICATION__DOBEFOREFINALIZATION(<error reading="reading" variable="variable">) at .\include\application.inc:1050
    #12 BEFOREFINALIZATION at forms.pp:1706
    #13 SYSTEM_INTERNALEXIT at :0
0
payl napisał(a)
  1. Dlaczego każdy do cholery zakłada że nic nie czytałem?
    bo jak ktoś próbuje zwolnić interfejs przez free to zazwyczaj nie ma pojęcia co robi.

A co do problemu to może jednak daj kod klasy oraz co robisz w create i destroy formy

0

jasne że się wywala albo nie zwalnia, ponieważ:

skoro używasz interfejsu, to powinieneś używać go wszędzie - nigdzie nie odwoływać się do obiektu przez TFoo, zawsze przez IFoo. wtedy nigdy nie wywołujesz metody Free, bo nawet jej nie masz.
obiekt zostanie zwolniony (z wykonaniem destruktora) gdy utraci wszelkie referencje.
skoro u ciebie obiekt się nie zwalnia, to znaczy że ma gdzieś zagubione referencje. wywołanie Free powoduje wywalenie zapewne z tego powodu, że te referencje są gdzieś wykorzystywane.

Dlaczego każdy do cholery zakłada że nic nie czytałem
może i czytałeś. na pewno za mało. jest jasne, że korzystasz z TInterfacedObject źle.

pokaż kod.

0

"o jak ktoś próbuje zwolnić interfejs przez free to zazwyczaj nie ma pojęcia co robi." - Nie zmienia to faktu że czytałem.
"skoro używasz interfejsu, to powinieneś używać go wszędzie - nigdzie nie odwoływać się do obiektu przez TFoo, zawsze przez IFoo." - Może w takim razie złej technologii używam?
skoro u ciebie obiekt się nie zwalnia" - akurat z tym problemu nie ma.
Ale po kolei, ponieważ jest to ogromny projekt, ciężko dać jakąś część kodu, więc wyjaśnię wam architekturę.
Mam klasę TFoo - która jest główną klasą, tworzy ona inne klasy (w tym TBar). TBar nie widzi TFoo (są w innnych unitach).
TFoo jest w unicie foo.pas
TBar jest w unicie bar.pas
unit foo.pas korzysta z unitu bar.pas (żeby móc używać obiektu TBar).
Jest jeszcze plik foo_basic.pas - jest on używany przez foo.pas i przez bar.pas - w nim znajduje się interfejs (IFoo), którego używam, żeby TBar mógł skorzystać z części procedur TFoo.
Póki co, działa wszystko poza niszczeniem sekcji krytycznej w procedurze TFoo.Done (nie jest to destruktor) - otrzymuje wyjątek "External: ?". Procedury TFoo i TBar działają normalnie, działa też interfejs IFoo (który jest podawany TBar przy okazji Create).
Tutaj macie kod (co prawda nie oryginalny, ale wyjaśnia zasadę).

constructor TBar.Create(intr:IFoo);
begin
  //Tutaj jest zapamiętywanie interfejsu. proste przypisanie
end;
constructor TFoo.Create;
begin
  bar:=TBar.Create(self);
  InitCriticalSection(x);
end;
procedure TFoo.Done;
begin
  bar.Free;
  DoneCriticalSection(x);//Tu jest błąd
end;

Obiekt Tfoo jest tworzony przy okazji tworzenia głównej formy aplikacji, a procedura Done jest wykonywana przy okazji niszczenia okna aplikacji.
Tutaj macie jeszcze kod IFoo (który znajduje się w foo_basic.pas) - tym razem kod oryginalny:

IFoo=interface
     function ActiveTasks:integer;
     function Active:boolean;
     procedure ShowMessage(a:ansistring);
   end;
0

na pewno bar.Free nie może tam być (generalnie nie może nigdzie być :p)
gdzie masz x zadeklarowany
nie jesteś w stanie stworzyć nowego projektu, z dwoma interfejsami (choćby nawet z jedną tylko metodą) i klasami je implementującymi, które by obrazowały to co próbujesz zrobić? Bo ja z tego co pokazałeś nic więcej nie potrafię wyczytać.

Na koniec tylko zwrócę uwagę, że FPC i Lazarus mogą mieć jakieś krzaki - masz możliwość przekompilować to w jakimś delphi?

0
Misiekd napisał(a)

na pewno bar.Free nie może tam być (generalnie nie może nigdzie być :p)
Czemu? :o

Misiekd napisał(a)

gdzie masz x zadeklarowany
W TFoo

Misiekd napisał(a)

Na koniec tylko zwrócę uwagę, że FPC i Lazarus mogą mieć jakieś krzaki - masz możliwość przekompilować to w jakimś delphi?
na razie nie, ale jeśli zajdzie taka potrzeba to się rozejrze.

Misiekd napisał(a)

nie jesteś w stanie stworzyć nowego projektu, z dwoma interfejsami (choćby nawet z jedną tylko metodą) i klasami je implementującymi, które by obrazowały to co próbujesz zrobić? Bo ja z tego co pokazałeś nic więcej nie potrafię wyczytać.
Oto kod, który ma symulować sytuację. Wszystko działa zgodnie z założeniami, poza sekcją krytyczna X (działa dobrze, a w głównej aplikacji mam crash)- czyżbym coś innego robił źle?

unit Unit1; 

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;
  IFoo=interface
    procedure ShowMessage(a:ansistring);
    end;
  TBar=class
    procedure GoShow;
    constructor Create(inter:IFoo);
    destructor Destroy;
    public
    intr:IFoo;
  end;

  TFoo=class(TInterfacedObject,IFoo)
    procedure ShowMessage(a:ansistring);
    constructor Create;
    destructor Destroy;
    procedure GoKill;
    procedure GoShow;
    public
      x:TRTLCriticalSection;
      bar:TBar;
  end;

var
  Form1: TForm1; 

implementation

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
var
  foo:TFoo;
begin
  foo:=TFoo.Create;
  foo.GoShow;
  //foo.Free;
  foo.GoKill;
  foo:=nil;
end;

procedure TBar.GoShow;
begin
  intr.ShowMessage('jupi!');
end;

constructor TBar.Create(inter:IFoo);
begin
  intr:=inter;
end;

destructor TBar.Destroy;
begin
end;

procedure TFoo.ShowMessage(a:ansistring);
begin
  form1.button1.caption:=a;
end;

procedure TFoo.GoShow;
begin
  EnterCriticalSection(x);
  bar.GoShow;
  LeaveCriticalSection(x);
end;

constructor TFoo.Create;
begin
  bar:=TBar.Create(self);
  InitCriticalSection(x);
end;

destructor TFoo.Destroy;
begin
  GoKill;
end;

procedure TFoo.GoKill;
begin
  bar.Free;
  DoneCriticalSection(x);
end;

{$R *.lfm}

end.
0

A więc końcem końców, zrozumiałem, że Od razu gdy referencje interfejsu osiągnął zero jest on czyszczony - i tutaj był problem, bo w mojej procedurze DoneCriticalSection było zaraz po kasowaniu referencji do interfejsu i kończyło się to tak, że DoneCriticalSection działał na już skasowanej klasie.
Dzięki wszystkim za tłumaczenie na czym polegają interfejsy (nadal uważam je za bezsensowne - chyba przesiądę się na klasy z virtual . ).

0

Generalnie Delphi jest trochę biedne jeśli chodzi o klasy virtualne. Klas virtualnych nie posiada - możesz mieć metody virtualne i generalnie to wszystko - nie możesz mieć klasy virtualnej tak jak np. w c#, gdzie nie możesz stworzyć obiektu danej klasy - tutaj to jest normalna klasa a jedynie próba wywołania metody virtualnej rzuci wyjątek.

0

nie możesz mieć klasy virtualnej tak jak np. w c#

mówisz o klasie abstrakcyjnej, którą trzeba dziedziczyć żeby wykorzystać?

<delphi>type TKlasa = class abstract
...
end;


wymaga w miarę nowej wersji Delphi.


> Generalnie Delphi jest trochę biedne jeśli chodzi o
generalnie Delphi z każdą wersją dostaje jakieś nowe elementy składni, dlatego powinien być obowiązek podawania posiadanej wersji przy każdym pytaniu o Delphi na forum :-)
0
Azarien napisał(a)

nie możesz mieć klasy virtualnej tak jak np. w c#

mówisz o klasie abstrakcyjnej, którą trzeba dziedziczyć żeby wykorzystać?

<delphi>type TKlasa = class abstract
...
end;

> 
> wymaga w miarę nowej wersji Delphi.
dokładnie o to. Tylko, że to jest gdzieś od wersji 2009


> generalnie Delphi z każdą wersją dostaje jakieś nowe elementy składni, dlatego powinien być obowiązek podawania posiadanej wersji przy każdym pytaniu o Delphi na forum :-)
ba nawet generyki się pojawiły :P :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1