[Solved]Weird AV in the LCL on app-close...

[cdbc]

Hi
All of a sudden, an ugly exception has begun to appear, when I close/free a TTabSheet containing a TFrame containing a TListView. It appears to be Font related as the fpdebugger takes me to: TFont.FreeReference; namely this piece of code:

Code: Pascal  [Select][+][-]

1. procedure TResourceCacheItem.DecreaseRefCount;
2.  
3.   procedure RaiseRefCountZero;
4.   begin
5.     RaiseGDBException('TResourceCacheItem.DecreaseRefCount=0 '+ClassName);
6.   end;
7.  
8. begin
9.   //debugln('TResourceCacheItem.DecreaseRefCount ',ClassName,' ',dbgs(Self),' ',dbgs(FReferenceCount));
10.   if FReferenceCount = 0 then <--- I land here with the debugger ? ! ?
11.     RaiseRefCountZero;
12.   dec(FReferenceCount);
13.   if FReferenceCount = 0  then
14.     Cache.ItemUnused(Self);
15.   //debugln('TResourceCacheItem.DecreaseRefCount END ');
16. end;
17.  

I have NO MonkeyBusiness going on, none whatsoever, just 3 event-handlers:
- OnDblClick
- OnKeyDown
- OnSelectItem
Would it perhaps be of any use, to disconnect them just before it all gets freed?!? (never had to do that before, but there's a first time for everything, I guess).
If I step it further in the debugger/cpuwindow everything around it seems to be nil...
For now I've wrapped the dang thing in exception handlers and the "DivisionByZero" exception from"RaiseGDBException" changes into an Access Violation when I can catch it.
It's safe to say, it annoys the h*** out of me  :'(
I'd be much obliged for any help you can give me 
Regards Benny

[d4eva]

Can you create a small, reproducible code example? It's hard to help without seeing the actual code.

[cdbc]

Hi
Well it's quite intricate, involving a lot of busines-logic behind the scenes...
But I can show you the code where the culprit resides:

Code: Pascal  [Select][+][-]

1.  
2. procedure TfrmLedger.pctMainCloseTabClicked(Sender: TObject);
3. var
4.   Dt: ptrint;
5.   Pg: TTabSheet;
6.   Fr: TfraListview;
7.   Fracc: TfraListview_acc;
8. begin { this is used, when we want to free a page on tab-close-button-click }
9.   Pg:= Sender as TTabSheet; { we get the perpetrator served on a silver platter }
10.   if Pg.Name = 'tabSettings' then exit; { swallow event, we don't want to close 'Settings' }
11.   Pg.OnShow:= nil; { we're freeing it anyway }
12.   Dt:= StrToInt(Pg.Hint); { get our datatype from otherwise unused hint prop }
13.   case Dt of
14.     0,2: begin
15.            Fr:= TfraListview(Pg.Tag); { does it contain a frame?  one could also simply do: TfraListview(Pg.FindChildControl('fraListview')) :o) }
16.            if Fr <> nil then begin { we haven't necessarily used fTextSearch, but if we have... }
17.              if Assigned(fTextSearch) then begin
18.                if Fr.Bom <> nil then fTextSearch.DetachDataset(Pg.Caption,Fr.GetBomIntf) { detach ourselves from textsearch }
19.                else fTextSearch.DetachDataset(Pg.Caption,nil); { bom already freed, detach to avoid AV }
20.              end;
21.              Fr.Fini; { if so, call its "destructor" }
22.            end;
23.          end;
24.     1: begin
25.          Fracc:= TfraListview_acc(Pg.Tag); { does it contain a frame?  one could also simply do: TfraListview(Pg.FindChildControl('fraListview')) :o) }
26.          if Fracc <> nil then begin { we haven't necessarily used fTextSearch, but if we have... }
27.            if Assigned(fTextSearch) then begin
28.              if Fracc.Bom <> nil then fTextSearch.DetachDataset(Pg.Caption,Fracc.GetBomIntf) { detach ourselves from textsearch }
29.              else fTextSearch.DetachDataset(Pg.Caption,nil); { bom already freed, detach to avoid AV }
30.            end;
31.            Fracc.Fini; { if so, call its "destructor" }
32.          end;
33.        end;
34.   end; // case
35.   if KKLOptions.RemoveItemOnClose then RemoveFileFromMainView(Pg.Caption);
36.   { and finally remove it formerly FreeAndNil(Pg); now Pg.Free; }
37.   {$ifdef debug} ErrorLog.LogLn('TfrmLedger.pctMainCloseTabClicked: Freeing Pg '+Pg.Caption+' @ '+DateTimeToStr(now+0.0417)); {$endif}
38.   try Pg.Free; except on E: Exception do //// <<--- Here Pg.Free; raises an AV
39.     begin
40.       ErrorLog.LogLn('Error! TfrmLedger.pctMainCloseTabClicked @ '+DateTimeToStr(now+0.0417)+#10+E.Message);
41.     end;
42.   end;
43. end;
44. {$undef debug}
45.  

This is what the log looks like:

TfrmLedger.pctMainCloseTabClicked: Freeing Pg 1000_kasse-03.2023 @ 12-3-23 11:04:50
Error! TfrmLedger.pctMainCloseTabClicked @ 12-3-23 11:04:50
Access violation

Everything is fine until Pg.Free; But it is not everytime it raises AV, just kinda when it feels like it. The frames are all alike.
Regards Benny

[Bart]

If you do Application.ReleaseComponent(Pg) instead of Pg.Free, does that help?

Bart

[jamie]

I remember something about the TTabSheet's property TAG was being used for internal use and it was questioned before, but I don't remember it ever being solved.

  This would mean it's possible the TAG property is changing one way or the other.

Looking at Laz docs I don't see it in the published list but it is in there for Delphi, this is a bug That I remember that no one wanted to cover, I guess.

[d4eva]

Is it still an AV if you comment out all, except the Pg.Free?

[jamie]

what are you doing in the OnKeyDown event?

[cdbc]

Hi
@Bart: Sorry Bart, that approach really wreaks havoc on the app, the pagecontrol doesn't know what's up and what's down, looks kinda funny 
@d4eva: Sorry, commenting and only freeing just gets me faster to TFont.FreeReference; and leaving all my b.logic leaking 
@Jamie: First off, OnKeyDowns are adding,editing & deleting items in a ListView... Second, I tried using FindControl instead of Tag and it runs just as fine, i.e.: it's not the business logic or Tag that's the problem. Just the dang "RaiseGDBException" in LCLResourceCache.DecreaseReference; (TFont.FreeReference).
Now I just log the exception and move on, data and app-logic etc. is safe and fine, maybe when I upgrade to 2.2.6, it will go bye bye...
Regards Benny

[jamie]

This is what I see from your comments.

You are manipulating controls that are or could be within the coming TabSheet that is getting ready to go away.

 The KeyDown happens before the CLICK.

 The click is the process of DOWN and UP.

 Much like most GUI window controls, these are message based, by making changes to a control in the key down, a message or messages get posted to the message que during that state but, the KeyUP will arrive first and thus, you may decide to delete that tabsheet and all controls living on it.

 when you are done there, then later on comes that stream of messages for a control that now does not exist, which in turn may not even show a fault at that time but could be doing damage like reducing resources that have already been reduced.

 This can lead to later problems.

 at the end of your KeyDown event, you could try calling the Application.Processmessages.
 This will purge and process messages waiting that you just put in there.
 GUI messages get put on a low priority in windows in most cases.

 So, it's a try with no guarantee that it will solve your problem. You really should work that out.

[cdbc]

Hi
Today I finally tracked down the culprit \o/
Deep in a plugin-module, I was creating, using and Freeing a StateMachine. with "fSM.Free;" everything was hunkydory.... Then in "Module.Destroy" I checked for "if Assigned(fSM) then fSM.Free;" // just to be sure, you know 
sometimes that error crept all the way up into the gui and into TFont.FreeReference; ?!?
Anyway, the fix is... Tadaaaa... FreeThenNil(fSM);
@Jamie: you were half right, it was something connected, just not OnKeyDown and friends...
This bug was a bit fiddly to find, to say the least 
Thank you for your tips and comments   
Regards Benny