Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 8 of 8 total |
Using Eurekalog with Dbisam Server |
Fri, Nov 12 2010 6:49 PM | Permanent 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent Link |
Raul 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Raul 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Raul 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 |
This web page was last updated on Sunday, May 5, 2024 at 07:30 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |