cancel
Showing results for 
Search instead for 
Did you mean: 

How to get Allocation Profiler to work with Delphi 7 application built with runtime packages. (BPL)

Highlighted
New Contributor

How to get Allocation Profiler to work with Delphi 7 application built with runtime packages. (BPL)

Hi,

 

We recently purchased a copy of AQTime pro (version 8.80.3749.7) for using on an old legacy D7 project and for the life of me I cannot seem to get the allocation profiler to work with applications built with runtime packages option.  Initially we thought this might be something to do with our delphi project itself but I went and created a very simple test project with a small class contained in a bpl in order to see if I could get this working.  This is a very basic test app written for the sole purpose of trying to get AQtime to respond.  we do not have any custom memory managers and Delphi 7 is updated to build 8.1  and I have also attached the test project for you in case it helps.

 

 

All the debug options are set for both the main application and the bpl. and both are added to the AQtime project along with rtl70.bpl and vcl70.bpl but nothing ever shows up in the results windows after running a test.  if we disable build with runtime packages it seems to work fine (as everything is contained in the exe itselff, however this is not an option for the actual main project as this consists of a few hundred bpl's). 

 

for what its worth the other profilers seem to work for the most part and I found a similar post here describing exactly the same issue all be it for c++ builder.: https://community.smartbear.com/t5/AQtime/Allocation-Profiler-with-bpl-files/m-p/46760   but none of the suggestions work for me either and the thread seems incomplete. 

 

Am I missing something or does AQtime 8 actually fully support Delphi 7

 

Thanks

4 REPLIES 4
Highlighted
New Contributor

Still no joy with this.  after further testing I updated the class in the bpl to inherit from TIntefacedObject and  the reference count profiler dosnt seem to work either.  I get there are no classes to profile message.  again unticking the packages and compiling a stand alone exe works fine. 

 

in addition to previous post I'm running windows 7 64bit with Delphi 7.  the application is 32bit. 

 

anyone any ideas ?

 

thanks 

Highlighted
New Contributor

Ok so I was playing around with this some more and removed the requires RTL from the bpl package in the test application to force it to include the rtl stuff and it started to profile correctly.
this implied that in order to get the allocation profiler to work and profile memory correctly we need a debug version of the borland rtl70.bpl file.

 

So I created one and replaced the rtl70.bpl in the system32 | SysWOW64 folder and re compiled the test app and it allocation profiler started working.

 

OK so now here's where it gets weird. although I could debug the test application fine (its very simple) when I rebult and tried to run the large legacy application I started getting exceptions
for third party libraries (zlib compression in this case) not finding references in rtl70.bpl

 

so I went back to system32 folder and renamed the debug bpl and put back the original borland rtl70.bpl and tried to run again and hey presto the allocaiton profiler was still working.

 

I suspected it may have something to do with the project being build with the debug version in place in the windows system folder so I rebuilt again with the original borland bpl back in place and sure enough the allocation profiler still seems to be working.  Why this is so I'm at a loss to explain yet but it seems creating the debug version seemed to blow the cobwebs out from under something somewhere in my aqtime\delphi setup so to speak.


For what its worth here's the steps to create the debug version of rtl70.bpl
NB) as mentioned above I am not actually using this in the system32 | SysWOW64 folder and back to the original rtl70.bpl. yeah its weird lol

 

- create a new delphi package project
- compile and you should get a message dialog to add rtl package to the requires section if its not already there
- go to project manager and expand the package requires section
- right click on rtl package and select open this should open the rtl package project.
- Create a new project folder where desired to save this debug version
- now save the rtl project as rtl70.dpk in your folder created above. (you can ignore the initial package project its only use is a means of opening the rtl package)
- now open project options for newly saved rtl70 package
- on description tab add a suffix to the description eg: Borland Run Time Library 70 (Debug)
- on linker and compiler tabs: set the debug flags for your delphi version as per AQtime documentation, I also included debug dcu option.
https://support.smartbear.com/aqtime/docs/profiling-with/prepare-apps/compiler-settings-native/index...
- Save Project again

 

- navigate to windows\system32 or windows\sysWow64 (depending on os version)
- backup/rename rtl70.bpl to rtl70_Borland.bpl (or something similar) do the same for rtl70.map or rtl70.dcp if present

 

- open a command prompt and navigate to your folder containing the debug rtl70.dpk
run the command: dcc32.exe rtl70.dpk to compile the bpl.**

 

- copy your newly compiled rtl70.bpl to the System32 | SysWow64 folder

- fireup AQ Time and Allocation profiler should now work

 

**) when building rtl70 I got missing .dcu references to two files namely VarHlpr.dcu and StrHlpr.dcu.
I couldn't find either a .pas or .dcu version of these anywhere in my install nor any references in delphi installed .pas files so commented them out of the package for now.
(this may come back to bite me later, so I will endevor to find a copy of these .pas files)


Anyway as mentioned at the moment I'm stumped at why swicthing back to original rtl70.bpl now works and in lieu of a better response and as this seems to be working for me so far for the moment I thought I'd post it here incase it helps anyone in a similar situation out of a hole.

 

I'll post updates if anything else comes to light.

 

 

 

 

Highlighted
Community Hero

Hi,

 

Thank you a lot for the detailed description of your actions and sorry for not replying earlier.

 

My guess is that AQTime was unable to access (debug?) version of some module and this prevented profiler from been able to function.

I believe that you followed the steps described in the documentation (https://support.smartbear.com/aqtime/docs/profiling-with/prepare-apps/compiler-settings-native/delph...).

Especially I am thinking about this note:

"If you want to keep Build with runtime packages (for instance to control exe size), you can still use the Allocation profiler. When you include your application in an AQTime project, you will also have to include the <Windows>\System32\VCLnn.BPL or <Windows>\System32\RTLnn.BPL file, [...]".

 

Also, SmartBear provides a really good technical assistance, so I would recommend to create Support ticket via the https://support.smartbear.com/message/?prod=AQtime form, reference this thread and ask for their recommendations.

 

Regards,
  /Alex [Community Hero]
____
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
https://community.smartbear.com/t5/custom/page/page-id/hall-of-fame
================================
Highlighted
New Contributor

Hi Alex,

 

Thanks for your response, yeah its all a bit strange but seems to be working ok for now.  unfortunately we must use the runtime packages as this legacy system has its own list of custom packages/bpl's of which there are several hundred so compiling into a standalone exe isn't really an option unfortunately.

 

we would also love to migrate to a more modern iteration of Delphi but again all the third party libraries and stuff are well embedded and some obsolete so the time required to update these etc.. would be more then its worth

 

In the meantime if I encounter any more issues I'll update this thread and maybe open a ticket if required.

 

thanks again

 

Phil

New Here?
Join us and watch the welcome video:
Announcements