2

I have a 3rd-party component that causes the Delphi IDE to stop responding (hang) when I try and close a project that has a form containing the problem component in it.

Is there an easy way to track where in the component's code the problem could lie?

Would it be reasonable to say that it is in the destructor of the component?

What steps would be recommended to try and narrow down the cause?

madExcept does not show anything so it does not seem to be an access violation problem.

Thanks for kind assistance.

user1202134
  • 233
  • 2
  • 10
  • Simple approch is to stuff some logging in to see where it blocks – David Heffernan Mar 02 '12 at 14:28
  • Last time I had such a problem it was a finalization section in one of the runtime or designtime units. These run when the BPL is unloaded. Rob's answer is the only sane thingyou can do. Bisecting such a problem with log messages could take all day. Debugging could take 10 minutes. Use the Debugger. – Warren P Mar 02 '12 at 15:23
  • Hi Warren P, I'm also wondering if it is in the finalization section of the registration of the component. In the finalization section, a callback hook object is freed and I'm wondering whether this is ever done. When does the finalization section of a component registration run? I have placed a ShowMessage statement in the finalization part and this message never appears. So, is the hook object ever getting freed? – user1202134 Mar 05 '12 at 07:41

1 Answers1

2

The same way you'd track down any other problem: Use the debugger.

Start Delphi and open a project. Set the project's "host application" to be Delphi itself. Run the project in the debugger, and another instance of Delphi should appear. In the new instance, reproduce the bug. When it hangs, go to the debugger (the first Delphi instance) and pause execution. Look at the call stack and find the bug.

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
  • Hi Rob Kennedy, thank you for your prompt reply. Excuse my ignorance -- please could you give me more details on how to 'set the project's host program to be Delphi itself? Also, the following steps you mentioned. Thank you for your kind assistance. – user1202134 Mar 02 '12 at 15:12
  • in delphi ide menus, click RUN -> PARAMETERS, put bds.exe into the Host Application box. – Warren P Mar 02 '12 at 15:25
  • Thanks for that Warren P. Will this method actually debug the IDE when it is closing the application? The problem does not occur while running the application with the component in it but when closing down the application (File -> Close All) then the IDE hangs. – user1202134 Mar 02 '12 at 16:28
  • Right. When Delphi is the host application, you're using the debugger of the first instance to *debug Delphi itself*. Since the problem you observe occurs while running Delphi, that's exactly what you need. You suspect that code in the component is causing a problem. That code is running in the context of the Delphi application, so debug Delphi and find the problem. You obviously won't have access to *all* the code, but if the component is compiled with debug information, the debugger should be able to use it. – Rob Kennedy Mar 02 '12 at 16:34
  • 1
    Ok, thanks Rob. So I've created a blank application and set the project's "host application" to Delphi (C:\Program Files\Borland\BDS\3.0\Bin\bds.exe). However, I'm not managing to get the second instance of Delphi going. When I run the project (F9), project runs (just displaying the blank form of the project) but I don't see the 2nd instance of the Delphi IDE to reproduce the bug. Your kind help is much appreciated – user1202134 Mar 02 '12 at 16:56
  • Hi Rob, could you please help me through the other steps. I've managed to set a blank project's "host application" to Delphi. However, I'm not getting it right to get the 2nd instance of Delphi going. When I run the project in debug mode (F9), it runs by displaying the blank form of my new project but there is no 2nd IDE to now create a new form and place the 'bad' component onto it to reproduce the bug. – user1202134 Mar 03 '12 at 04:48