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

Comments

• 16 Comments sorted by Votes Date Added
• Eugene Balabuev (LMD)

  October 2018 Posts: 0Vote Up0Vote Down

  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

  November 2018 Posts: 0Vote Up0Vote Down

  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

  November 2018 Posts: 16Vote Up0Vote Down

  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

  November 2018 Posts: 0 Accepted Answer Vote Up0Vote Down

  >> 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)

  November 2018 Posts: 0Vote Up0Vote Down

  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

  November 2018 edited November 2018 Posts: 16Vote Up0Vote Down

  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

  November 2018 Posts: 16Vote Up0Vote Down

  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

  November 2018 Posts: 16Vote Up0Vote Down

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

  regards

  Dave.
  
• Eugene Balabuev (LMD)

  December 2018 edited December 2018 Posts: 0Vote Up0Vote Down

  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

  December 2018 Posts: 16Vote Up0Vote Down

  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

  December 2018 Posts: 16Vote Up0Vote Down

  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)

  December 2018 Posts: 0Vote Up0Vote Down

  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

  December 2018 Posts: 16Vote Up0Vote Down

  Eugene,

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

  Thanks in advance.

  regards

  Dave.
  
• Eugene Balabuev (LMD)

  December 2018 Posts: 0 Accepted Answer Vote Up0Vote Down

  Fixed.
• David Hoyle

  December 2018 Posts: 16Vote Up0Vote Down

  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)

  December 2018 Posts: 0Vote Up0Vote Down

  Already published as a part of 2019.1 release.