Devart Forums

Hello,

I have a strange problem with memoryleak. I'm using tclientdataset-tdatasetprovide-tuniquery. If there is a blob field in query, there is a memory leak. It is not always and not for all queries. I have tried to make demo to reproduce this problem, but with demo app all works ok.
This problem is in our production app. I found this circumstances for my problem:

- when FetchRows=25 everything is always ok. Problem starts with FetchRows>25 for example 100, 200 etc. When =100 there are 8 TOraLob objects leaked, when 200 there are 16 object leaked etc.
- it is all about BLOB fields and CreateComplexField/FreeComplexField functions. The first one is called more times than another one.

I'm trying to debug code with UniDac source, but it's hard to understand code (of course, not my code).

Do you have any ideas about this situation?

XE2 upd4 hotfix 1, 32bit, vcl app, Oracle oci 10g.

Thanks
Zdenek

Edited: this occurs when result is empty (no rows in database)

Edited: I think the problem is in FetchArray (OraClassesUni) in procedure

procedure ClearBlock;
var
i: integer;
Item: PItemHeader;
begin
// Free complex filds
if not HasComplexFields then
Exit;
for i := 0 to FFetchRows - 1 do begin
Item := PtrOffset(Block, sizeof(TBlockHeader) + i * ItemSize);
if Item.Flag <> flFree then //---- HERE THE FLAG IS NOT INITIALIZED BEFORE
FreeComplexFields(PtrOffset(Item, sizeof(TItemHeader)) , True);
end;
end;

hello,

We couldn't reproduce the problem you have described. If you can't create a test application demonstrating the problem, please describe in more details the steps causing the error, and send the table dump to alexp*devat*com

Demo app sent.

Zdenek

Any progress on this?

Thanks
Zdenek

hello,

We got your project , however, we couldn't reproduce the situation when the Item.Flag property would equal flFree. We will continue researches and let you know the results as soon as we get them.

It is very rarely, because .Flag is not initialized (radnom memory value). I depends on what it was in memory block before.

hello,

We still could'nt reproduce the problem, however, we will try to modify the check for necessity of releasing fields in order to avoid situations when Flag is equal to flFree

Change my demo to this code:

procedure TForm21.Button1Click(Sender: TObject);
var I: Integer;
p:pointer;
begin
for I := 1 to 100 do begin
ClientDataset1.Open;
ClientDataset1.Close;
Getmem(P,100000);
FillChar(p^,100000,221);
Freemem(p);
end;
end;

and you have got 100% of memoryleak.

Thanks
Zdenek

Hello,

Thank you for the sample, we have reproduced the problem and will try to fix it in the nearest version.

Is this problem solved with new 4.5 version?

Thanks
Zdenek

We have tested your demo with these changes on several OSs and different IDEs:
and couldn't reproduce this issue. Please test your demo with UniDAC 4.5 and post the result here. If the issue is not resolved, then we will continue investigation of this issue.

I have tested 4.6.11 version and memory leak is still here.

Hello,

This problem is already fixed , the new version with the fix will be released this week.

Thanks a lot.

Hi , i'm having problems with BackupToFile with UniDump, at the end shows an access violation in a PostGreSQL database. The error only occurs with a few tables , and is related to FreeComplexFields .

My version is 4.6.12 UniDAC . I found that even with the error, the dump file is created with all the contents.

I found that by disabling the property UniDirectional, the command works without problems. But I can not disable this feature as it would affect other system routines.
I downloaded the trial version 5.1 of UniDAC to perform a test and with the latest version, I can use the command BackupToFile smoothly the first time we used it , but if you try to run a second time the system has no access violation but stays with status " Not Responding " .

I wonder if there is a way around this problem or have some other version of UniDAC where the command BackupToFile work properly.