Subject | Re: [IBO] IBO BUG: Resource Leak in IB_Components (verified in C++ Builder 6) |
---|---|
Author | Geoff Worboys |
Post date | 2005-08-18T00:40:40Z |
zachs78 wrote:
using BPLs there seems to be no memory leak that I can detect.
Its been a long while since I used C++Builder to do VCL work
(these days I use Delphi for VCL work and MSVC for C++, my
C++Builder install just sits their for an old UDF library that
I have been too busy to convert over to MSVC). This is just
in way of explanation for the following silly question...
When you do:
#pragma link "IB_Components"
I take it that all the dependent objs are also linked (I guess
they must be or you would not have been able to debug the
init/final sections ib_session). I am just wondering whether
there is any chance that not everything needed is actually
linked into the DLL - whether you may be trying to have the
DLL use runtime libraries (loading BPLs) causing possible
duplication of objects between the DLL and the BPL with
unpredictable consequences.
The other thing that seems likely to cause difficulties is that
various parts of the core library do interesting things like
provide default dialogs (for login, progress reporting and
error display), they also do things like refer to the global
Application and Screen objects. None of these aspects are
likely to be happy trying to operate over a DLL interface where
RTTI information is not available and the various globals are
not likely to be defined (at least not appropriately).
I cant see where any of these issues would be causing you a
memory leak (as opposed to a runtime error of some sort) but
I do think you are in for "interesting times" in the future.
If you can do a "normal" VCL application using IB_Components,
perhaps you can use codeguard to check for leaks on that. This
at least would give Jason something more easily reproduceable
(in Delphi) to work with, and may allow codeguard to give more
useful information about the location of the leak.
--
Geoff Worboys
Telesis Computing
> It was executed properly, both the initialization andI certainly cant see anything obvious - in a simple example
> finalization sections. I even removed that part (i.e. no
> initialization / finalization) and the #pragma link
> "IB_Components" still gave the same problem.
> I don't think it's a simple one.
using BPLs there seems to be no memory leak that I can detect.
Its been a long while since I used C++Builder to do VCL work
(these days I use Delphi for VCL work and MSVC for C++, my
C++Builder install just sits their for an old UDF library that
I have been too busy to convert over to MSVC). This is just
in way of explanation for the following silly question...
When you do:
#pragma link "IB_Components"
I take it that all the dependent objs are also linked (I guess
they must be or you would not have been able to debug the
init/final sections ib_session). I am just wondering whether
there is any chance that not everything needed is actually
linked into the DLL - whether you may be trying to have the
DLL use runtime libraries (loading BPLs) causing possible
duplication of objects between the DLL and the BPL with
unpredictable consequences.
The other thing that seems likely to cause difficulties is that
various parts of the core library do interesting things like
provide default dialogs (for login, progress reporting and
error display), they also do things like refer to the global
Application and Screen objects. None of these aspects are
likely to be happy trying to operate over a DLL interface where
RTTI information is not available and the various globals are
not likely to be defined (at least not appropriately).
I cant see where any of these issues would be causing you a
memory leak (as opposed to a runtime error of some sort) but
I do think you are in for "interesting times" in the future.
If you can do a "normal" VCL application using IB_Components,
perhaps you can use codeguard to check for leaks on that. This
at least would give Jason something more easily reproduceable
(in Delphi) to work with, and may allow codeguard to give more
useful information about the location of the leak.
--
Geoff Worboys
Telesis Computing