Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Using Eurekalog with Dbisam Server
Fri, Nov 12 2010 6:49 PMPermanent Link

Kong Aw

I thinking I have a memory leak in my own code in the DBISAM server. I have Eurekalog.  How do I exit the server so that Eurekalog will report the memory leak?
Sat, Nov 13 2010 10:06 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

KK,

<< I thinking I have a memory leak in my own code in the DBISAM server. I
have Eurekalog.  How do I exit the server so that Eurekalog will report the
memory leak? >>

If you're using the DBISAM Database Server as a service, then just use:

net stop dbsrvr

from a Windows command prompt (Admin required).

--
Tim Young
Elevate Software
www.elevatesoft.com
Sun, Nov 14 2010 10:06 PMPermanent Link

Kong Aw

Thanks Tim.

For some reason, Eurekalog is not reporting any errors although the dbsrvr is consuming lots of memory.  I suspect it is inside some new routines that I have added recently for pdf files and image manipulations.  The routines will stop functioning properly when a huge amount of memory is consumed by dbsrvr (as shown in task manager).  

Any suggestions where else I should look.

KK Aw
Mon, Nov 15 2010 3:07 PMPermanent Link

Raul

Team Elevate Team Elevate

Hi,

While i have not used the Eurekalog memory leak reporting i know the FastMM one is very good and can even create a text file with leak details - see if Eurekalog can do same thing.

Having said that there are memory leaks that are not really leaks from memory manager perspective and hence not caught by it.

For example if you do something like this in a function/procedure:
...
 Table := TDBISamTable.Create(Application);
  Table.TableName := 'x';
  Table.Open;
   ...

(note that you do not Table.Free  in this function)

We all can agree that it's a memory leak from code perspective - we lost track of the allocated object when you exit the function and re-create a new one each time.

However technically you are not leaking any memory since it will be all cleaned up when you exit the application  - meanwhile the app memory consumption will keep going up until it likely will crash.

I suggest you review all your object and memory allocations and free them as soon as you're done with them.

Raul
Tue, Nov 16 2010 4:22 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Raul

>Having said that there are memory leaks that are not really leaks from memory manager perspective and hence not caught by it.
>
>For example if you do something like this in a function/procedure:
>..
> Table := TDBISamTable.Create(Application);
> Table.TableName := 'x';
> Table.Open;
> ...
>
>(note that you do not Table.Free in this function)
>
>We all can agree that it's a memory leak from code perspective - we lost track of the allocated object when you exit the function and re-create a new one each time.
>
>However technically you are not leaking any memory since it will be all cleaned up when you exit the application - meanwhile the app memory consumption will keep going up until it likely will crash.

That's true of just about anything (eg TStringList.Create without a .Free) - its cleared up when the app closes, but FastMM reports it.

Roy Lambert [Team Elevate]
Tue, Nov 16 2010 1:56 PMPermanent Link

Raul

Team Elevate Team Elevate


>That's true of just about anything (eg TStringList.Create without a .Free) - its cleared up when the app closes, but >FastMM reports it.

Sorry but i don't believe that is correct. Memory leak reporting AFAIK is only performed on app exit so as long as "something" frees the objects at the end there are no leaks. The something is either owner class or you yourself.

TStringlist type object does not take an owner as part of it's constructor so it will always leak unless you free it. It is not cleaned up by anything and is always reported by FastMM as memory leak.

Any VCL type component though only leaks if it has no parent and you don't free it.

b := TButton.Crete(nil); //this will always leak unless you free it yourself. It is reported by FastMM

b := TButton.Create(Application); //this will never leak from FastMM perspective as app shutdown frees it (app is its parent)


Hence if you have something as follows and call it repeatedly your app memory usage goes thru the root but nothing is leaked as per FastMM:

procedure x;
var
 t:TButton;
begin
 t:=TButton.Create(Application);
 //do something actually useful here ....
end;

Raul
Wed, Nov 17 2010 2:35 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Raul


You're right. I missed the (Application) - mainly because I only use it for forms.

Roy Lambert
Wed, Nov 17 2010 1:05 PMPermanent Link

Raul

Team Elevate Team Elevate

> You're right. I missed the (Application) - mainly because I only use it for forms.

Yes, in most cases one would probably use something like <component>.Create(self); inside a form or datamodule in which case those objects would be the owners.

Raul
Image