Subject | Re: [IBO] Memory Leaks Problem |
---|---|
Author | jrodenhi |
Post date | 2007-01-05T16:11:37Z |
Hi Hans,
Thanks for responding. I also do not get reports of memory leaks when
I run outside the IDE, but I think that is because I used the line
ReportMemoryLeaksOnShutdown := DebugHook <> 0;
If I make that
ReportMemoryLeaksOnShutdown := True;
I get reports whether I run within or outside the IDE. You might
also. I have run my program under MemProof. Although it does not
report that something was not freed, it has this complaint:
Attempt to free unexisting resource
and it points to a Prepare statement in my code here:
Procedure TSQL.Prepare(sSQL: TStringList);
Begin
SQL := sSQL;
Inherited Prepare;
bFirst := True;
End;
I don't know why it should complain about attempting to free an
unexisting resource at that point. This is why I think that there is
something expected of me as the programmer using IBObjects that I am
not doing or something I am doing that is wrong.
Any more help is appreciated.
-Jack
Thanks for responding. I also do not get reports of memory leaks when
I run outside the IDE, but I think that is because I used the line
ReportMemoryLeaksOnShutdown := DebugHook <> 0;
If I make that
ReportMemoryLeaksOnShutdown := True;
I get reports whether I run within or outside the IDE. You might
also. I have run my program under MemProof. Although it does not
report that something was not freed, it has this complaint:
Attempt to free unexisting resource
and it points to a Prepare statement in my code here:
Procedure TSQL.Prepare(sSQL: TStringList);
Begin
SQL := sSQL;
Inherited Prepare;
bFirst := True;
End;
I don't know why it should complain about attempting to free an
unexisting resource at that point. This is why I think that there is
something expected of me as the programmer using IBObjects that I am
not doing or something I am doing that is wrong.
Any more help is appreciated.
-Jack
--- In IBObjects@yahoogroups.com, Hans <hhoogstraat@...> wrote:
>
> Running from the Delphi IDE, I always get some memory leak reports, but
> then running stand alone, none at all. Mind you, I may not use the same
> components
> as you do. Anyways, according to docs of FastMM you can generate
> detailed logs by defining/setting some {$VARIABLES} and following
> the instructions in the docs of the mentioned MemProof program in
setting
> up your compiler / linker options, you should be able to find the
offensive
> byte of code :)
>
> Hans
>
> >I am experiencing some persistent memory leak issues and although they
> > seem to be related to IBObjects, they are undoubtedly because I am not
> > following a correct protocol in using the objects rather than anything
> > wrong with the library.
> >
> > I think my arrangement is pretty simple. In my MDI application, I
> > create a TConnect called MainConnection and make its owner the main
> > form so it gets destroyed when the main form is destroyed. Then I
> > create a class called TSQL which inherits from TIB_Query. I added
> > some TStringLists to it for the headings, to store SQL statements and
> > retrieve results. My create and destroy methods look like this:
> >
> > Constructor TSQL.Create(AOwner: TComponent);
> > Begin
> > Inherited;
> > FSQL := TStringList.Create;
> > FVal := TStringList.Create;
> > FHeadings := TStringList.Create;
> > SetLength(FWidths, 0);
> > IB_Connection := MainConnection;
> > bFirst := True;
> > inc(FCounter);
> > FIndex := FCounter;
> > End;
> >
> > Destructor TSQL.Destroy;
> > Begin
> > If (IB_Transaction <> nil) then begin
> > if IB_Transaction.TransactionIsActive then IB_Transaction.Commit;
> > IB_Transaction.Free;
> > IB_Transaction := nil;
> > end;
> > FHeadings.Free;
> > FHeadings := nil;
> > FSQL.Free;
> > FSQL := nil;
> > FVal.Free;
> > FVal := nil;
> > Unprepare;
> > Params.ClearBuffers(rsNone);
> > Inherited Destroy;
> > End;
> >
> > When I exit my program, FastMM reports a bunch of memory leaks
like this:
> > An unexpected memory leak has occurred. The unexpected small block
> > leaks are:
> >
> > 1 - 12 bytes: String x 7, Unknown x 11
> > 13 - 20 bytes: TList x 44, String x 12, Unknown x 18
> > 21 - 28 bytes: TIB_TransactionDMLCache x 1, String x 21, Unknown x 4
> >
> > 29 - 36 bytes: String x 8, Unknown x 13
> > 37 - 44 bytes: TIB_TimeoutProps x 1, String x 4
> > 45 - 52 bytes: String x 5, Unknown x 2
> > 53 - 60 bytes: TStringList x 4, String x 19
> > 61 - 68 bytes: TIB_StringList x 26
> > 69 - 76 bytes: TIB_StringCache x 1, TIB_StringProperty x 45, String x
> > 1, Unknown x 4
> >
> > 85 - 92 bytes: TIB_UpdateSQL x 1
> > 101 - 108 bytes: TIB_ConnectionLink x 2, Unknown x 5
> > 109 - 116 bytes: TIB_TransactionLink x 1
> > 117 - 124 bytes: TIB_SchemaCache x 1
> > 133 - 140 bytes: TIB_Row x 3
> >
> > 149 - 156 bytes: TIB_SQLStrings x 1
> > 173 - 188 bytes: Unknown x 4
> > 189 - 204 bytes: TIB_ColumnText x 2
> > 205 - 220 bytes: TIB_ColumnInteger x 1
> > 237 - 252 bytes: Unknown x 3
> > 285 - 300 bytes: TIB_MasterDataLink x 1, TIB_KeyDataLink x 1
> >
> > 349 - 380 bytes: Unknown x 1
> > 381 - 412 bytes: TIB_Session x 1, TIB_TransactionInternal x 1
> > 445 - 476 bytes: Unknown x 3
> > 573 - 620 bytes: TConnect x 1
> > 669 - 732 bytes: Unknown x 1
> >
> > 1053 - 1148 bytes: Unknown x 1
> > 1261 - 1372 bytes: TIB_Dataset x 1
> >
> > The sizes of unexpected leaked medium and large blocks are: 4908
> >
> > Can anyone help me figure out my little problem on this?
> >
> > Thanks for your help.
> >
> > -Jack
> >
>