Eurekalog 7 Reports an attempt to use a Destroyed Object when closing a Dock Panel

David Hoyle

Hi,

I've tried to implement LMD Docking into one of my existing applications and I found that EurekaLog was reporting an attempt to use a freed object.

I've spent time today to ensure its not my code as in one instance it was but after fixing I ended up with the same issue.

I decide to open the pDockingDemo project provide and enable EurekaLog and have found the same attempt to use a detroyed object when closing panel using the X on the panel.

I've attached the EurekaLog bug report (I hope it helps). I've not had any false positives from EurekaLog so I do not think the problem is in their code.

I'm using LMD 2018 Release 2018.3 and EurekaLog 7.7 on RAD Studio 10.2.3 Tokyo Enterprise.

If you need any more information then please let me know.

regards

Dave.

Eugene Balabuev (LMD)

I cannot reproduce this issue. I installed Eurekalog, and imitated "bad" code to check that all setup is made properly. However, no problems occured with closing docking panels, including dynamically created text-document panels, including floating panels.

A.C.D. De Lier BV

Hi,

I have the same issue and found the problem and solution:

procedure TLMDDockPanel.WndProc(var Message: TMessage);

begin

  inherited;                                  // Eventually calls BeginAutoDrag.

  if psBeginAutoDragCalled in FState then     // Dispatch disabled by Vcl code

  begin                                       // mouse messages to support Vcl's

    Exclude(Fstate, psBeginAutoDragCalled);   // default mouse calls chain, e.g.

    try

     Dispatch(Message);                        // MouseDown virtual procedure.

    except

     // Do nothing

    end;

  end;

end;

Dispatch calls an already destroyed panel, surrounding it with a try..except is a workaround not solving the problem.

In debug mode it works as expected, in normal mode I have to use the workaround.

Regards,

Peer 

David Hoyle

I'm glad you've managed to reproduce the bug. Alas, I don't have the code so I cannot add the workaround. I had the same issue that in debug mode (in the IDE) it worked but standalone it did not.

regards

Dave

Rafael Maricca

>> I don't have the code so I cannot add the workaround. <<

FYI: All our products include full source code. Just download the source installer from your customer area (it is a separate installer called "Source").

Eugene Balabuev (LMD)

A.C.D. De Lier BV, can you check, whether the following will work instead of try-except:

if not (csDestroying in ComponentState) then

  Dispatch(Message);

If it will work for you, please let me know, and I'll add this to LMD code-base.

David Hoyle

Rafael,

Thanks for letting me know about the source. Unfortunately with 10.2.3 I could not compile my app with the source so I had to add the LMDDckSite.pas file to my app to be able to test the code.

Alas, the code above does not work. The state of the ComponentState property I think is undefined at this time as I get the following from the debugger for that property at the point in time it is called:

[csWriting,csDesigning,csAncestor,csUpdating,csFreeNotification,(out of bound) 12,(out of bound) 14,(out of bound) 15]

regards

Dave.

David Hoyle

Okay, I tried something else that worked...

I created an enumerate for the dock panel as follows:

  TDGHLMDDockPanelState = (ldpsUnknown, ldpsAlive, ldpsDead);
In the dock panel I added a new private field:

    FDGHLMDDOckPanelState : TDGHLMDDockPanelState;
In the constructor I set the value as follows:

  FDGHLMDDOckPanelState := ldpsAlive;
And in the destructor as follows:

  FDGHLMDDOckPanelState := ldpsDead;
and updated the WndProc as follows:

    if FDGHLMDDOckPanelState = ldpsAlive then
      Dispatch(Message);
Now this worked and EurekaLog didn't raise an issue BUT FDGHLMDDockPanelState is undefined at this point as the debugger says its value is "(out of bounds) 116" and I think its pure luck that this works.

I think the correct solution would be to unhook the WndProc somehow in the destructor but I suspect thats deep in the VCL code so at this time I do not know how to achieve this.

regards

Dave

David Hoyle

Sorry, I accepted the answer for the source code instead of rejecting the code suggestion. Can anyone reverse this?

regards

Dave.

Eugene Balabuev (LMD)

Can you try one more thing. Please add the call to standard Destroying method to the panel's destructor as shown:

{ ---------------------------------------------------------------------------- }

destructor TLMDDockPanel.Destroy;

begin

  Destroying;  // <--------

  InternalSetLoadingSite(nil);

  InternalResetSite;

  UpdateHook(False);

  Images := nil;

  HeaderMenu := nil;

  FImageChangeLink.Free;

  FDsgDragRect.Free;

  inherited;

end;

It should set standard csDestroying flag from the destructor begining, and thus, my proposal with "if not (csDestroying in ComponentState) then..." should begin to work. So, we will need no additional enumeration.

I've actually already incorporated this way into latest code version, but, please let me know how it will work.

David Hoyle

Unfortunately, no this doesn't work as the memory is being accessed after the object is destroyed...

ComponentState = [csWriting,csFixups,csFreeNotification,(out of bound) 14,(out of bound) 15]

Question: What is it in the destructor chain that removed this components WndProc from the messaging system?

regards

Dave.

David Hoyle

So I've done a little more debugging of the original problem and the call to the WndProc in TLMDDockPanel is originating from TApplication.ProcessMessages and the message ID is 45089 which definitely is not a standard WM_#### message as WM_USER is 1024 and above. Looking through your code I cannot see anything above WM_ISTHEMEDCONTROL = WM_USER + 2398. So I've implemented the following which I think is safer...

    If Message.Msg <= WM_USER + 2398 Then
      Dispatch(Message);                      // MouseDown virtual procedure.

regard

Dave.

Eugene Balabuev (LMD)

This is quite strange, because Destroying is effectively the same as declaring additional flag field. However, I've actually was unable to reproduce situation with Destroying or any other method, like enumeration field, ect.

Also, Release of docking panels, which is used by caFree in OnClose event handlers, have been implemented analogous to standard TForm.Release. It actually uses asynchronous PostMessage with custom message Id to be sure that real destruction is performed outside of all other logic flow.

David, can you create a small demo and send it to our support email (https://lmd.de/mfs) along with description of steps to reproduce.

David Hoyle

Eugene,

I've sent an email with the relevant files and instructions.

Thanks in advance.

regards

Dave.

Eugene Balabuev (LMD)

Fixed.

David Hoyle

Eugene,

Thanks for the fix. I assume it will appear in the next release cycle so for now I need to include the modified source?

regards

Dave

Eugene Balabuev (LMD)

Already published as a part of 2019.1 release.