V jednom prípade mi aplikácia ukončuje s AV

[Stanislav Hruška]

Samotný podformulár je jednoduchý.

[vandrovnik]

Problém může vznikat i na úplně jiném místě - třeba někde jinde alokuješ paměť, ale zapíšeš do ní víc, než se vejde. Nebo nemáš inicializovaný nějaký pointer či objekt a zapisuješ do paměti, na kterou odkazuje.

[Radek Červinka]

Totálne tomu nerozumiem. Mám nasledovné:

Kód: Delphi [Vybrat]

1. procedure TfrmsubEntry.btnCancelClick(Sender: TObject);
2. begin
3.   oEntry.CancelRecord;  //  OK
4. end;
5. .
6. procedure TfrmsubEntry.actCancelExecute(Sender: TObject);
7. begin
8.   oEntry.CancelRecord;  //  AV
9. end;

Krokoval som to riadok po riadku. Samozrejme, že to je totožné.
Ja pre to nenachádzam žiadne vysvetlenie.

uz si nejsi jist ze oGlobalVar nebo oGlobalVar.ActualObject je spravne. Tipl bych to na problem s tim druhym, ze uz byl uvolnen, nebo je nil.

ActualObject je správny. Overoval som to. Objekty sa uvoľňujú jedine pri uzatvorení formulára. Pozriem sa na to. A to s editáciou nemá nič spoločné.

Zkusil jsi FastMM ve fulldebug mode?

Mám ho takto vždy!

A zkusil jsi zda ti FastMM detekuje dvojite uvolneni atd?, tj. treba
var
  lst: TStringList;
begin
  lst := TStringList.Create;
  lst.Free;
  lst.Free; // <- tady ti to musi odchytnout
end;


Jinak co je oEntry a kde se uvolnuje?

[Radek Červinka]

Jinak co je oEntry a kde se uvolnuje?

A mas nastaveno use debug dcu? Jaky je call stack v pripade vyjimky s use debug dcu?

[Stanislav Hruška]

Problém může vznikat i na úplně jiném místě - třeba někde jinde alokuješ paměť, ale zapíšeš do ní víc, než se vejde. Nebo nemáš inicializovaný nějaký pointer či objekt a zapisuješ do paměti, na kterou odkazuje.

Ja také "ťažké" techniky nepoužívam.

A mas nastaveno use debug dcu? Jaky je call stack v pripade vyjimky s use debug dcu?

Mám. Žiaden výpis sa mi nezobrazí. Keď dám pokračovať tak sa program ukončí. Pri Brek skočí do jednotky System.
Project JasotSVB.exe raised exception class $C0000005 with message 'access violation at 0x77912163: read of address 0xfeeefefa'.

A zkusil jsi zda ti FastMM detekuje dvojite uvolneni atd?, tj. treba

To nie.
oEntry je objekt v podstate ako každý iný. Uvoľňuje sa v tom zozname TObjectlist<T>. V tomto prípade ich tam je 14.

Opakujem sa: vykonaný kód je totožný. Myslím tým aj vo vzťahu k iným objektom. Nachádza sa totiž mimo objektu. V predkoch, TCustomDB a v Navigators.
Jediné čo rozhoduje o AV je miesto volania oEnter.CancelRecord. Z ActionManager AV, z tlačidla OK. V ostatných skúšaných objektoch sa to nestane.

[pf1957]

Nerozumiem ako môže vyvolanie Table.Edit vyvolať také správanie.

Ale to je jen dusledek chyby, kdy aplikace po sobe zameta a vola Finalization sekci v kazde unit, ktera ji ma a v aplikaci se vyskytuje bez ohledu na to, jestli je tvoje nebo ne.
To je jen indukovana chyba.

IMHO nejjednoduzsi bude dat bkpt do FinalizeUnits na radek

Kód: Delphi [Vybrat]

1. TProc(P)();

a kazde do kazdeho volani vtrasovat (F7) tak dlouho, nez narazis na unit, ve ktere to spadne. Casto to nezachytis tak, abys vedel pri cem, takze dalsi bkpt do te unit, ve ktere to spadlo a dalsi pokus dotrasovat se priciny atd. Pri trose stesti se to rozsviti, co mas spatne, az uvidis, po cem to saha.

Rekl bych, ze pricinou bude neporadek v zivotnim cyklu nejakeho objektu a ze sahas po necem, co v te dobe je uz uvolnene a zbyl ti nekde dangling pointer. A FastMM to nechyti, protoze to FinalizeUnits se vola skoro az na same konci exitu v Halt nebo tak odnekud.

[Radek Červinka]

A FastMM to nechyti, protoze to FinalizeUnits se vola skoro az na same konci exitu v Halt nebo tak odnekud.

Dovolil bych si nesouhlasit. FastMM ma byt jako prvni jednotka v dpr, takze jeji finalization (kde se kontroluji leaky atd.) je tim padem jako posledni volana (pravdepodobne krome system.pas). Finalization sekce jsou volany v obracenem poradi.
 Navic dvojite uvolneni atd. se kontroluje v prubehu behu programu.

[Radek Červinka]

Opakujem sa: vykonaný kód je totožný.

Evidentne neni, jinak by to nespadlo. Tak bud chces poradit, nebo ne.

[Stanislav Hruška]

Evidentne neni, jinak by to nespadlo. Tak bud chces poradit, nebo ne.

Keby som nechcel radu, tak sa nepýtam. Ja tu píšem o svojom kóde. A vo formulári som žiaden rozdiel nezistil.

IMHO nejjednoduzsi bude dat bkpt do FinalizeUnits na radek

Skončil som na Out of memory. V PC bolo obsadených 68% a Delphi 700MB.
Skúsim to ešte raz.

[Stanislav Hruška]

Dopracoval som sa k tomu a potom

Kód: Delphi [Vybrat]

1. procedure DoneControls;
2.  
3. begin
4.   FreeAndNil(FlagControl);
5.   Application.Free;  //  Tu mi to padne

[Stanislav Hruška]

Pokračovanie:

Kód: Delphi [Vybrat]

1. destructor TApplication.Destroy;
2.     DestroyWindow(FHandle);  //  Tu bolo číslo, ale z neho nezistím nič.
3. function DestroyWindow; external user32 name 'DestroyWindow';

Tu som definitívne skončil.

[vandrovnik]

Stejně mi připadá pravděpodobnější, že chyba jako taková je někde úplně jinde (a spíš v aplikaci než ve VCL).
Třeba něco jako:

Kód: Delphi [Vybrat]

1. btn1:=tButton.Create...
2. btn2:=btn1;
3. FreeAndNil(btn1);
4. btn2.něco; // pravděpodobně AV

[Stanislav Hruška]

Presnejšie je koniec tu po druhom prechode

Kód: Delphi [Vybrat]

1. System.Classes
2. { Standard window procedure }
3. function StdWndProc(Window: HWND; Message: UINT; WParam: WPARAM; LParam: WPARAM): LRESULT; stdcall;
4. {$IF Defined(CPUX86)}
5. { In    ECX = Address of method pointer }
6. { Out   EAX = Result }
7. asm
8.         XOR     EAX,EAX
9.         PUSH    EAX
10.         PUSH    LParam
11.         PUSH    WParam
12.         PUSH    Message
13.         MOV     EDX,ESP
14.         MOV     EAX,[ECX].Longint[4]
15.         CALL    [ECX].Pointer
16.         ADD     ESP,12
17.         POP     EAX
18. end;
19. {$ELSEIF Defined(CPUX64)}

[Stanislav Hruška]

Stejně mi připadá pravděpodobnější, že chyba jako taková je někde úplně jinde (a spíš v aplikaci než ve VCL).

To si myslím aj ja. Lenže
Keby som mal Tebou uvedený príklad, tak by mi to muselo padnúť stále (a aj inde). Ja FreeAndNil používam v Destroy a samozrejme vo funkciách. Ale tam takmer vždy až na konci. A aj to na 99% v try...finaly

[vandrovnik]

Právě že to v takových případech nemusí padat vždycky - v závislosti na tom, co se zavolá a co se mezitím dělo v paměti.

Dnes jsem zrovna řešil chybu zavlečenou ještě z dávných verzí - pole záznamů, uvnitř záznamu string (dřív tam bylo string[5]). Položky v poli se posouvaly pomocí move - a to je problém, protože položky "přeplácnuté" novými záznamy neuvolnily ty stringy a naopak stringy z původní a z nové pozice měly špatně čítač referencí, takže pak při zápisu do původní položky už string v nové položce ukazoval vlastně na neplatnou paměť.