Access violation při ukončení programu

[Jirka]

Pomohl by mě někdo rozkodovat informaci kde mohla vzniknout chyba - vznika víceméně náhodně a málokdy
Vypis je z MadExceptu ..

compiled with      : Delphi XE2
madExcept version  : 5.1.1
callstack crc      : $d04c8d70, $18878b4e, $18878b4e
exception number   : 1
exception class    : EAccessViolation
exception message  : Access violation at address 0040386F in module 'aplikace.exe'. Read of address 00000000.

main thread ($1778):
0040386f +017 aplikace.exe System           2914 +14 SysFreeMem
00404984 +004 aplikace.exe System           3502 +20 @FreeMem
00408d80 +01c aplikace.exe System          19241 +14 @UStrClr
0040ab08 +08c aplikace.exe System          26173 +70 @FinalizeArray
0040aa50 +024 aplikace.exe System          26006 +21 @FinalizeRecord
0040703e +012 aplikace.exe System          13131 +13 TObject.CleanupInstance
00406f81 +005 aplikace.exe System          13005  +1 TObject.FreeInstance
004d6c89 +019 aplikace.exe madExcept                 InterceptClassDestroy
00487363 +023 aplikace.exe System.Classes   4721  +3 TPersistent.Destroy
00406fd0 +008 aplikace.exe System          13025  +1 TObject.Free
008a54d0 +01c aplikace.exe frxClass        14181  +2 TfrxView.Destroy
008a817a +032 aplikace.exe frxClass        15192  +4 TfrxCustomMemoView.Destroy
00406fd0 +008 aplikace.exe System          13025  +1 TObject.Free
0089e2d6 +036 aplikace.exe frxClass        11337 +13 TfrxComponent.Clear
0089d995 +03d aplikace.exe frxClass        11046  +7 TfrxComponent.Destroy
008a092e +03a aplikace.exe frxClass        12451  +9 TfrxReportComponent.Destroy
008ae0a5 +03d aplikace.exe frxClass        17091  +5 TfrxBand.Destroy
008aedfc +01c aplikace.exe frxClass        17374  +2 TfrxDataBand.Destroy
00406fd0 +008 aplikace.exe System          13025  +1 TObject.Free
0089e2d6 +036 aplikace.exe frxClass        11337 +13 TfrxComponent.Clear
0089d995 +03d aplikace.exe frxClass        11046  +7 TfrxComponent.Destroy
008af82b +027 aplikace.exe frxClass        17611  +3 TfrxPage.Destroy
008b061b +04f aplikace.exe frxClass        17976  +7 TfrxReportPage.Destroy
00406fd0 +008 aplikace.exe System          13025  +1 TObject.Free
008318ee +12e aplikace.exe frxPreviewPages   491 +25 TfrxPreviewPages.ClearPageCache
008316bd +015 aplikace.exe frxPreviewPages   427  +2 TfrxPreviewPages.Destroy
00406fd0 +008 aplikace.exe System          13025  +1 TObject.Free
008be8b4 +01c aplikace.exe frxClass        24392  +2 TfrxPreviewPagesList.Destroy
00406fd0 +008 aplikace.exe System          13025  +1 TObject.Free
00460f4c +008 aplikace.exe System.SysUtils 22337  +2 FreeAndNil
008b2f8a +072 aplikace.exe frxClass        19169 +11 TfrxReport.Destroy
00493adf +057 aplikace.exe System.Classes  12686 +10 TComponent.DestroyComponents
00493823 +01b aplikace.exe System.Classes  12558  +3 TComponent.Destroy
004953f6 +066 aplikace.exe System.Classes  13690  +6 TDataModule.Destroy
00493adf +057 aplikace.exe System.Classes  12686 +10 TComponent.DestroyComponents
00611955 +035 aplikace.exe Vcl.Forms        2127  +9 DoneApplication
0045622a +026 aplikace.exe System.SysUtils  4719  +6 DoExitProc
00408abd +065 aplikace.exe System          18563 +44 @Halt0
01dd2c9f +0c7 aplikace.exe sklepmistr        106 +17 initialization
758ffa27 +017 KERNEL32.DLL                             BaseThreadInitThunk

thread $213c: <priority:2>
767c19bf +4f user32.dll               GetMessageA
004d6ead +0d aplikace.exe madExcept CallThreadProcSafe
004d6f17 +37 aplikace.exe madExcept ThreadExceptFrame
758ffa27 +17 KERNEL32.DLL             BaseThreadInitThunk
>> created by main thread ($1778) at:
751334b5 +00 winmm.dll

[Radek Červinka]

Budu hadat: v datamodulu mas nejaky report z fastreportu, ktery budto neni inicializovany nebo uz byl uvolnen nejak explicitne?

[Marek Weyda]

Tyhle chyby jsou většinou kvůli nějakému opakovanému uvolňování z paměti. Mně to často v minulosti vznikalo nějakými dvojkliky uživatelů tam, kde se má kliknout jenom jednou nebo uživatelům se zdálo, že program nějak dlouho pracuje, tak klikali všude možně a vždy se jim něco podařilo zbořit. Toto ale mám už dost ošetřené. V současné době ale řeším také jednu záhadu. Když se podívám na výpis Vašeho zásobníku, tak TfrxPreviewPages.Destroy Vám proběhne v pohodě. Mně se to ale boří právě na této události (respektive na TfrxPreviewPages.Clear, kdy to uvolňuje TfrxXMLItem a tam někde to padne na násilný přístup). Absolutně nevím, jak se to těm uživatelům daří. Ty chyby mi chodí téměř výhradně od těch, co právě mají problém s dvojkliky nebo jsou to "šílení" klikači. Podle mě něco ve Fast Reportu vykliknou. Nemáte někdo nějaký nápad ? Můj zásobník vypadá takto:

Zásobník výjimky
Výpis zásobníku, generováno 24.08.2021 12:32:47
(00004D24){SlimOffice.exe} [00405D24] System.@LStrClr + $C
(00003D6E){SlimOffice.exe} [00404D6E] System.TObject.CleanupInstance + $12
(00024A8C){SlimOffice.exe} [00425A8C] Classes.TThreadList.UnlockList + $4
(00029011){SlimOffice.exe} [0042A011] Classes.RemoveFixups + $71
(000020BC){SlimOffice.exe} [004030BC] System.@FreeMem + $4
(00004D34){SlimOffice.exe} [00405D34] System.@LStrClr + $1C
(000020BC){SlimOffice.exe} [004030BC] System.@FreeMem + $4
(00004D34){SlimOffice.exe} [00405D34] System.@LStrClr + $1C
(00005C72){SlimOffice.exe} [00406C72] System.@FinalizeArray + $4A
(00005BFC){SlimOffice.exe} [00406BFC] System.@FinalizeRecord + $20
(00003D6E){SlimOffice.exe} [00404D6E] System.TObject.CleanupInstance + $12
(00003CB1){SlimOffice.exe} [00404CB1] System.TObject.FreeInstance + $5
(000040AE){SlimOffice.exe} [004050AE] System.@ClassDestroy + $2
(0014D029){SlimOffice.exe} [0054E029] frxXML.TfrxXMLItem.Destroy (Line 378, "frxXML.pas" + 5) + $6
(00003D00){SlimOffice.exe} [00404D00] System.TObject.Free + $8
(0014D049){SlimOffice.exe} [0054E049] frxXML.TfrxXMLItem.Clear (Line 385, "frxXML.pas" + 4) + $9
(0014D001){SlimOffice.exe} [0054E001] frxXML.TfrxXMLItem.Destroy (Line 374, "frxXML.pas" + 1) + $2
(00003D00){SlimOffice.exe} [00404D00] System.TObject.Free + $8
(0014D049){SlimOffice.exe} [0054E049] frxXML.TfrxXMLItem.Clear (Line 385, "frxXML.pas" + 4) + $9
(0014D001){SlimOffice.exe} [0054E001] frxXML.TfrxXMLItem.Destroy (Line 374, "frxXML.pas" + 1) + $2
(00003D00){SlimOffice.exe} [00404D00] System.TObject.Free + $8
(0014D049){SlimOffice.exe} [0054E049] frxXML.TfrxXMLItem.Clear (Line 385, "frxXML.pas" + 4) + $9
(0014D001){SlimOffice.exe} [0054E001] frxXML.TfrxXMLItem.Destroy (Line 374, "frxXML.pas" + 1) + $2
(00003D00){SlimOffice.exe} [00404D00] System.TObject.Free + $8
(0014D049){SlimOffice.exe} [0054E049] frxXML.TfrxXMLItem.Clear (Line 385, "frxXML.pas" + 4) + $9
(0014D612){SlimOffice.exe} [0054E612] frxXML.TfrxXMLDocument.Clear (Line 584, "frxXML.pas" + 1) + $3
(0018EEB4){SlimOffice.exe} [0058FEB4] frxPreviewPages.TfrxPreviewPages.Clear (Line 396, "frxPreviewPages.pas" + 3) + $3
(001D4065){SlimOffice.exe} [005D5065] frxClass.TfrxReport.ShowReport (Line 11137, "frxClass.pas" + 5) + $8
(00BED51B){SlimOffice.exe} [00FEE51B] frxSOLoader.TfrxSOLoader.Tisk (Line 605, "frxSOLoader.pas" + 51) + $6

[mbx]

Mozna ze u novejsich verzi uz to neni pravda, ale: ve zdrojacich FR 3, ktery (stale jeste) pouzivam ja, najdes na vice mistech processmessages - vola se behem pripravy sestavy. Takze pokud spustis nejaky slozitejsi report, mas sanci/cas uspesne kliknout na close hlavniho okna, zpracuje se AltF4, nebo cokoli jineho.
Ja jsem to vyresil tak, ze vsechny reporty jdou pres modalni dialog, kteremu se vse disabluje az do zobrazeni reportu.

[Jirka]

Mohu poprosit o pomoc při rozkodování  ..

Kód: Delphi [Vybrat]

1. FastMM has detected an error during a free block scan operation. FastMM detected that a block has been modified after being freed.
2.  
3. Modified byte offsets (and lengths): 44(2), 48(8)
4.  
5. The previous block size was: 1648
6.  
7. This block was previously allocated by thread 0x12C4, and the stack trace (return addresses) at the time was:
8. 41B652 [FastMM4.pas][FastMM4][FastMM4.DebugReallocMem][9888]
9. 450F54 [EMemLeaks.pas][EMemLeaks][EMemLeaks.EurekaReallocMem][5331]
10. 451181 [EMemLeaks.pas][EMemLeaks][EMemLeaks.EurekaReallocMem][5428]
11. 404D77
12. 40C3CA
13. 40C4A6
14. 137B114 [DuoObjects.pas][DuoObjects][DuoObjects.TDataDuoPoleDeis.Append][139]
15. 48C42B [System.SysUtils.pas][System][System.SysUtils.Trim][6007]
16. 160EB48 [FirebirdUtilAplikace.pas][FirebirdUtilAplikace][FirebirdUtilAplikace.NaplnitPoleCisNadoby][13319]
17. 7EB0AF [Data.DB.pas][Data][Data.DB.TField.GetData][4539]
18. 1AF614F [CisHM64RowsEdit2021A.pas][CisHM64RowsEdit2021A][CisHM64RowsEdit2021A.TFoHM64RowsEdit2021A.AktualizovatSeznamNadob][127]
19.  
20. The allocation number was: 1096084
21.  
22. The block was previously freed by thread 0x12C4, and the stack trace (return addresses) at the time was:
23. 41B6C9 [FastMM4.pas][FastMM4][FastMM4.DebugReallocMem][9922]
24. 451181 [EMemLeaks.pas][EMemLeaks][EMemLeaks.EurekaReallocMem][5428]
25. 404D77
26. 40C3CA
27. 40C4A6
28. 137B114 [DuoObjects.pas][DuoObjects][DuoObjects.TDataDuoPoleDeis.Append][139]
29. 48C42B [System.SysUtils.pas][System][System.SysUtils.Trim][6007]
30. 160EB48 [FirebirdUtilAplikace.pas][FirebirdUtilAplikace][FirebirdUtilAplikace.NaplnitPoleCisNadoby][13319]
31. 7EB0AF [Data.DB.pas][Data][Data.DB.TField.GetData][4539]
32. 1AF614F [CisHM64RowsEdit2021A.pas][CisHM64RowsEdit2021A][CisHM64RowsEdit2021A.TFoHM64RowsEdit2021A.AktualizovatSeznamNadob][127]
33. 1AF71BA [CisHM64RowsEdit2021A.pas][CisHM64RowsEdit2021A][CisHM64RowsEdit2021A.TFoHM64RowsEdit2021A.NaplnitCiselCombBoxy][392]
34.  
35. The current thread ID is 0x12C4, and the stack trace (return addresses) leading to this error is:
36. 41C88C [FastMM4.pas][FastMM4][FastMM4.CheckBlocksOnShutdown][11468]
37. 41D76A [FastMM4.pas][FastMM4][FastMM4.FinalizeMemoryManager][13030]
38. 41D7DA [FastMM4.pas][FastMM4][FastMM4.Finalization][13129]
39. 409434
40. 40981A
41. 1F266DC [sklepmistr.dpr][sklepmistr][sklepmistr.sklepmistr][115]
42. 7722FA29 [BaseThreadInitThunk]
43. 77747A7E [RtlGetAppContainerNamedObjectPath]
44. 77747A4E [RtlGetAppContainerNamedObjectPath]
45.  
46. Current memory dump of 256 bytes starting at pointer address 7E4ED400:
47. 98 A2 FA 01 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
48. 80 80 80 80 80 80 80 80 80 80 80 80 01 00 80 80 00 00 00 00 00 AB E5 40 80 80 80 80 80 80 80 80
49. 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
50. 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
51. 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
52. 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
53. 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
54. 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

[Stanislav Hruška]

Ja len tak tipujem, žo to treba hľadať v

• BaseThreadInitThunk, alebo
• RtlGetAppContainerNamedObjectPath

Skôr som za druhú možnosť, nakoľko sa tu objavuje 2x

[pf1957]

Mohu poprosit o pomoc při rozkodování 

- poprve objekt vytvoris pri volani na radku #18
- na radku #33 ho zrusis - od radku #22 do vypada stejne jako od #18. To vypada jako nejaky auto-create nebo co - to bys mel videt, co to dela a kdy a proc se to vola
- no a pak v ramci shut-downu aplikace se to znovu snazis uvolnit. Takze bude pri uvolneni do instance priradit nil, aby opakovane volani nic nedelalo, nebo "narovnat" spravu zivotniho cyklu.

[Radek Červinka]

Mohu poprosit o pomoc při rozkodování 

- poprve objekt vytvoris pri volani na radku #18
- na radku #33 ho zrusis - od radku #22 do vypada stejne jako od #18. To vypada jako nejaky auto-create nebo co - to bys mel videt, co to dela a kdy a proc se to vola
- no a pak v ramci shut-downu aplikace se to znovu snazis uvolnit. Takze bude pri uvolneni do instance priradit nil, aby opakovane volani nic nedelalo, nebo "narovnat" spravu zivotniho cyklu.

S tim souhlasim, podle mne bude problem to DuoObjects.TDataDuoPoleDeis, staci ho pri uvolneni nastavit na nil.

[Jirka]

Objekt je typu record a je public Property vlastní komponenty děděné z TCustomComboBox.
Objekt nikde explicitně nevytvářím a pouze v OnDestroy komponenty volám TDataDuoPoleDeis.Clear

Problém se vyskytu jen občas a pokud nastavím forAll  testovaní    (i se 10 000 voláním) tak se  závada neobjeví ...

Už jsem i uvažoval že "record"  opustím a převedu to do klasického objektu s Tlist  který mi bude udržovat potřebný seznam recordů  rInfoListZaznam;

Kód: Delphi [Vybrat]

1.    TDataDuoPoleDeis = record
2.     PoleData: array of rInfoListZaznam;
3.     procedure Append(const Value: rInfoListZaznam);
4.     function Count: integer;
5.     function NajdiZaznamPodleId(const AId: String;Out AVystupZaznam: rInfoListZaznam  ): Boolean;
6.     procedure Clear;
7.  
8. rocedure TDataDuoPoleDeis.Append(const Value: rInfoListZaznam);
9. begin
10.  
11.   SetLength(PoleData, length(PoleData) + 1);
12.   PoleData[high(PoleData)] := Value;
13.   PoleData[high(PoleData)].ASize:=Length(Value.ANazevValue);
14.   end;
15. //------------------------------------------------------------------------------
16. procedure TDataDuoPoleDeis.Clear;
17. begin
18.  SetLength(PoleData,0)
19. end;
20. //------------------------------------------------------------------------------
21.  
22.  

[pf1957]

Objekt nikde explicitně nevytvářím a pouze v OnDestroy komponenty volám TDataDuoPoleDeis.Clear

Ten mechanismus Append/Clear se i zda OK.

Problém se vyskytu jen občas a pokud nastavím forAll  testovaní    (i se 10 000 voláním) tak se  závada neobjeví ...

No to bude nejspis zaviset na obsahu a/nebo operaci, ktere uzivatel s tim ComboBoxem ev. necim jinym dela. Nesouvisi to treba s pouzitim funkce NajdiZaznamPodleId? BTW, co delas s hodnotou AVystupZaznam?

[Jirka]

delas s hodnotou AVystupZaznam?

Myslím že nic neobvyklého..
Používám to v té mé komponentě u jedne funkce

Kód: Delphi [Vybrat]

1. function TDBSmartComboBox.VratTextPodleId(AIdVstup: Integer): string;
2. var
3.   WorkInfoListZaznam: rInfoListZaznam;
4.     Nalezeno:Boolean;
5.   begin
6.  
7.  
8.    begin
9.     inherited;
10.      SearchInfo.IdValue:=intToStr( AIdVstup);
11.      Nalezeno:= CiselnikDatovePole.NajdiZaznamPodleId(SearchInfo.IdValue,WorkInfoListZaznam);
12.     if Nalezeno then
13.      Result:=WorkInfoListZaznam.AViewTextValue else
14.      Result:='';
15.  
16.  
17.     end;
18.    end;
19. //--------------------------------------------------------------------------------------------------------------------------------
20.  
21.  

nemůže být problém v uvolnování recordu  ?
(.. že nejsou pevné délky stringů ..)
viz definice

Kód: Delphi [Vybrat]

1.  
2. rInfoListZaznam =  packed record
3.       Index:Integer;
4.       ACodeValue:String;
5.       ANazevValue:String;
6.       AIdValue:String;
7.       AUserValue:String;
8.       AViewTextValue:String;
9.       ASize:Cardinal;
10.       end;
11.  

[Radek Červinka]

Mne to porad prijde ze si ten rekord typu TDataDuoPoleDeis nekde predavas pres pointer, tj. ze si pamatujes referenci na nej, a na konci se to pres nej snazis jeste pracovat, ale interni pole uz je pryc.
Stejne mi to prijde divne, ja bych TDataDuoPoleDeis zmenil na tridu a interni zbytek (to pole) nechal. Myslim si, ze tak se ten problem rychle objevi.

[pf1957]

Myslím že nic neobvyklého..

Vypada to tak - mas to jen v autpmaticke promenne, takze kdyz opustis scope, tak to reference count drzet nebude.

nemůže být problém v uvolnování recordu  ?
(.. že nejsou pevné délky stringů ..)

AFAIK tak nemuze: ty dynamicke stringy se promitaji do recordu jako pointer na heap a za recordy je schovan obrovsky overhead, ktery se snazi vsechny ty managed typy memberu finalizovat.

Record je hodnotovy typ, takze pokud definujes promennou, prekladac pro nej vymezi kus pameti a neuvolnuje ho, jen na nej zavola Finalize(). Takze pokud ten record nealokujes pomoci GetMem(), tak se nic neuvolnuje.