madshi,
Thank you very much for your very kind collaborative attitude.
Your LeakTest confirms that madExcept.ReportLeeksNow is effective. But, unfortunately, not always. And very probably it is not your fault. This observation is suggested by further tests I did in my "non-academic"
environment.
Let me recall:
1. MyUdfs.dll is registered with an IB database (say, DB) addressed by MyApp.exe, see 2.. DB is accessed by MyApp via IB Server 2009. When MyApp connects to DB, the IB server becomes aware of UDFs (User Defined Functions) registered with DB, and knows that UDFs are hosted by MyUdfs.dll. The server loads the dll when, for the first time, an SQL code executed by the server calls an UDF exported by MyUdfs.dll.
MyUdfs.dll was compiled (Delphi XE8) to be "madExcept aware" (i.e. during MyUdfs "load_&_init" madExcept starts memory allocations monitoring, at least of allocations done by MyUdfs code).
BTW, madExcept is the very first unit in the "uses" clause of MyUdfs.pas. In the same clause there exist several units, one of them is MyUdfs_U1.pas. MyUdfs_U1, in its "initialization" section allocates an ObjectList and, symmerically, frees it in its "finalization" section. I hope that madExcept monitoring takes into account both allocation and deallocation of the ObjectList.
Am I right?
2. MyApp.exe is an application addressing DB (via the IB server); for my tests it was compiled (Delphi XE8) without "madExcept awarness". MyApp implements certain tasks - let us call them "DB-calculations" - that are done via Stored Procedures hosted in DB and executed by the IB server.
The particularity is that the only Stored Procedures calling UDFs hosted in MyUdfs are those related to (i.e. launched by) DB-calculations.
My tests concern only one DB-calculation, hence one stored procedure (SP) to which I added, as the last line, a call to ReportLeaksNow_UDF (more about it below), a new UDF that I included in MyUdfs.dll.
During the tests
- MyUdfs is compiled with debugging information,
- MyUdfs is run as attached, within debugger, to the process ibserver.exe,
- a breakpoint is set within ReportLeaksNow_UDF code,
- MyApp.exe is run without debugger,
- in MyApp.exe I launch manually the DB-calculation,
- after several seconds the debugger (in ibserver.exe process) stops on the breakpoint,
- I press F9.
What happens next depends on the below test variant ...
Test 1
Leaks reporting UDF is declared
Code: Select all
procedure ReportLeaksNow_UDF;
begin
{$IFDEF madExcept}
madExcept.ReportLeaksNow; //breakpoint line
{$ENDIF}
end;
After leaving ReportLeaksNow_UDF nothing happens.
Let me add that now, contrary to what I experienced on May 22, I see no madExceptViewer process in Task Manager (mystery?).
Test 2
Leaks reporting UDF is declared
Code: Select all
procedure ReportLeaksNow_UDF;
begin
{$IFDEF madExcept}
madExcept.SetLeakReportFile (a_file_pathName);
madExcept.ReportLeaksNow; //breakpoint line
{$ENDIF}
end;
After leaving ReportLeaksNow_UDF the report appears in the indicated file, ready for dragging to madExceptViewer.
My guess: IB prevents UDFs from launching a new process (e.g. madExceptViewer). If it's the case, I congratulate the IB team (no irony!); I am not qualified to do any investigation on so deep level.
Test 3
Leaks reporting UDF is declared
Code: Select all
procedure ReportLeaksNow_UDF;
begin
{$IFDEF madExcept}
madExcept.SetLeakReportFile (a_file_pathName);
{$ENDIF}
end;
and the line
Code: Select all
{$IFDEF madExcept}
madExcept.ReportLeaksNow; //breakpoint line
{$ENDIF}
is added at the end of the "finalization" section of MyUdfs_U1.pas (i.e. almost at the end of "fini_&_unload" stage of the dll stay within ibserver.exe process.
After passing the first break, when the DB-calculation was finished, I have quit MyApp.exe apparently provoking MyUdfs.dll unloading; debugger stopped in "finalization" section of MyUdfs_U1.pas and F9 resulted - as in Test 2 - in leaks report written to the indicated file. Moreover the report should be of better quality, i.e. less "apparent" leaks.
Test 4
Leaks reporting UDF is declared as in Test 3 but nothing is added to the "finalization" section of MyUdfs_U1.pas.
I hope that madExcept unit, seeing that it's going to be unloaded, will call itself a kind of ReportLeaksNow.
But ..., no room for dreams,
no file with leak report.
That's all about my tests. From the purely pragmatic point of view I can say that I've got a solution (Test 3). For you as the author my description can be useful, at least I hope. Maybe you are able to "correct" madExcept in the spirit of Test 4.
Concerning your answer
To answer your question: Leak reporting should work fine if you enable it in a 32bit project. There are no funny requirements, except that the madExcept32.dll needs to be available. As long as madCollection is properly installed, the DLL should be automatically available and found by madExcept.
it can satisfy only somebody who needs no understanding. For various reasons, my installations, files organization and unwillingness to let anybody to tinker my code, have very few in common with the "default" case. I'm not proud of that but I consider it optimal in my situation. But it needs my understanding where, given a tool as madExcept, the tool expects to find particular file(s) or needs a particular setting. This is just an example of info which you could present in form of the
Check List I've mentioned.
Besides the Check List I see just few very easy improvements, so the tool seems very good. But that will be subject of another post.
Kind regards,
JK